Thanks for bringing this up and describing the problem so clearly. I'm
going to answer with a bunch of questions in the hope it will lead us
into the right direction for this problem.
Dan Korostelev wrote:
> Another solution which I like much less is to move those adapters to
> "zope.authentication" and define an extra dependency (sigh) on
> zope.publisher, but then the package won't be so nice, clean and
> generic as it could be. :-)
One question I have is how theoretical this genericity is. Do we have
concrete use cases for using this zope.authentication outside of a Zope
context? What would that look like? Do we really expect people to show
up and say: "hey, I'll use this for my project that doesn't use
zope.publisher at all!".
We can also ask it in another way: if zope.authentication were not to
depend on zope.publisher, would zope.principalregistry not depend on
zope.publisher either? What about zope.app.authentication and
z3c.authenticator? (imagining any of their ZMI away for now). Would
*those* packages then be useful independently from zope.publisher?
I still feel bad about zope.publisher needing to know about
authentication (in the dependency sense) where it doesn't today. Is that
really true: does it today really not do anything with authentication?
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -