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 - 
 http://mail.zope.org/mailman/listinfo/zope )

Reply via email to