[Zope3-dev] proposal: allow contained PAU plugins
Gary Poster
gary at zope.com
Fri Jan 13 21:58:21 EST 2006
On Jan 13, 2006, at 6:34 PM, Roger Ineichen wrote:
> Hi Gary
Hey Roger
>
> [...]
>
> All arguments are Ok for me.
Cool.
> 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
as possible.
> 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
the problem.
>> Risks:
>> 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
> developed plugins.
>
> 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
chunks.
Thanks for your thoughts
Gary
More information about the Zope3-dev
mailing list