On Jan 13, 2006, at 6:34 PM, Roger Ineichen wrote:
All arguments are Ok for me.
But I think the PAU at all is to complex
and this whoul not change.
Do we really need such a complex authentication module in z3?
Well, I know it has come in handy for us. Also, though YMMV, I find
it actually much simpler to understand than the Zope 2 PAS--which was
also developed because ZC needed the flexibility. Jim, and then
Garrett, I understand, have tried to make the Z3 PAU as streamlined
What does this mean to the queriable sources and their API?
I assume you mean, what does my proposed change mean there. Not
much, as far as I can tell. The getQueriables method on the
authentication utility would use the new approach to get the
authenticator plugins, but nothing much would change for the
queriables (unless a queriable *wanted* to act differently when it
got a plugin found via containment, I suppose).
A long time ago I was improving the grant form in z3 and implemented
a grant vocabulary based on queriable sources. All I can say
about that part is, it's too complex and hard to develope with.
Yes, we didn't bother with the PAU queriable source pattern but did a
much simpler, less flexible, but more practical one still using the
PAU data. There might not be a good one-size-fits-all approach to
Some additional complexity, perhaps.
I'm sure we will get additional complexity.
But I can live with that. The only question is, should the PAU
be a component where other people can use as a base and develope
additional concepts like different UI or is, the PAU is only a
core component where only should be used for register custom
I guess the real problem is, that the PAU supports only
modularity for register own plugins all other parts are
implemented as none replacable component and you need some
functionality whcih is not implemented right now.
Two replies to this.
First, in this particular case, the problem was that the PAU design
had called YAGNI on this kind of use case, and now I do need it. It
was a PAU design problem, and I don't think that it's necessarily an
example of the need for more modularity.
Second, you might be right anyway that we need more modularity and
flexibility; however, I still hold out hope that the design is
sufficient, or can be with relatively minor refactoring. The
combination of credential plugins, authentication plugins, a
malleable principal object, and events and subscribers is pretty
powerful; ordered subscribers might be needed eventually, but that's
an older and broader topic with old discussion.
Also, making the PAU more modular will make it more complex, which
was your first concern in the email. There's definitely a tension
between flexibility and complexity, and it's worth trying to see what
we keep simple.
I'm a little afraid that this is not the only refactoring
in the next future if we not support more modularity in PAU.
You might be right that the PAU will in for a bigger refactoring in
the future. For now, I'm happy with trying to tackle it in smaller
Thanks for your thoughts
Zope3-dev mailing list