[Grok-dev] towards a new publisher

[Chris McDonough]

> Chris McDonough wrote:
>> One other very important thing... I would make the base system work
>> without any need for thread locals.  If I continued to use the ZCA, this
>> change would imply that there would always be a "registry" (ZCA registry
>> object) attached to the request and programmers would be expected to use
>> it; the global ZCA API would not work.
>
> I was wondering why a view registry would need to be attached to the
> request instead of, say, an the application object?

It's sort of just a matter of access.  Views always receive a request
object as an argument, so attaching the registry to the request provides
access to the registry without requiring the user to use any threadlocal
API.  The registry may contain info other than view info, too, like
utility registrations and so on.

> For adapter registries this makes less sense, though, so perhaps the
> request is a better place to put this kind of stuff.
>
> Could you go into some details of why you dislike thread locals? Harder
> to test?

Yes, they make it necessary to go into exhaustive detail when explaining
how to test things.  Lots of the testing-related questions we get to the
maillist are related to confusion about making sure the tests have access
to "the right" ZCA registry, and how to populate things.  This is despite
the fact that we try pretty hard to discourage people from using the BFG
ZCA registry in BFG apps; Zope people are very used to using the ZCA so
they want to use it anyway.

In Zope this isn't really a problem, because there can be only one
registry.  But once you turn the ZCA global API into something that looks
up a thread local, even though it's straightforward code-wise, it's awful
hard to explain in docs.  We gave it a good stab but it's still a pain
point:

http://docs.repoze.org/bfg/1.3/narr/threadlocals.html

http://docs.repoze.org/bfg/1.3/narr/unittesting.html

Also, use of thread locals makes it harder to use the framework with a
WSGI server that is event-driven rather than threaded.  In general, once
you have any APIs that rely on thread-local lookups, it's hard to use a
server that isn't either threaded or single-thread-only-without-events.