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
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to