[Zope-PTK] Stability rule-of-thumb (fwd)
Mike Pelletier
mike@digicool.com
Thu, 3 Feb 2000 16:40:13 -0500 (EST)
You [Ty] da geek! Something like this is _sorely_ needed, and not
just for the PTK but in general. I thought starting from GUF would mean
less work for me, but making someone else write it is even less work
still! ;-) I was not aware of the drawbacks to using GUF that you
brought up (which I think are extremely valid for most portals, and indeed
anything with lots of users). Additionally, GUF is a roll-your-own style
model, whereas I'm looking for a plugin model. Given all this, perhaps
GUF is not the best starting point.
Let me try to nail down my requirements... Basically, what I want is
a Zope Product which provides a class that fulfils the interface defined
by BasicUserFolder. You should be able to plug in potential
Authentication and Storage components by installing additional Zope
Products. They'd use an interface like--
from Products.NewUserFolder import RegisterAuthenticator
class MyAuthenticator:
...
RegisterAuthenticator(MyAuthenticator, "My Cool Authenticator")
--but really I don't care. 'NewUserFolder' is a placeholder for the
real name, whatever that is. You'll have to define the component API, I
don't have any particular requirements.
This new UserFolder's User objects will of course conform to the
BasicUser interface, with an addition: Users need to support
propertysheets. If not all storage plugins support propertysheets, that's
fine, but only ones which do will be useful for the PTK, so there should
be a way to ask. I need to be able to add and remove propertysheets (and
their properties) after users have been created.
I don't have an immediate need to be able to cycle through multiple
Authenticators, but if that's a feature you do need I think it's just
swell. It would be necessary to to able to enable/disable individual
Authenticators on a per-UserFolder instance basis.
If my confused rambling is not specific enough, I can define the
interface I need in more concrete terms. (uml model, abstract python
classes, whatever) What do you think of the scale of this project? Am I
asking for too much? What should we call this beastie? ;-)
> If this architecture (or something like it) makes sense to you, I'd be
> willing to devote part of my time, (and nearly all of Ty's time :) ) to
> assisting with design and implementation. And I don't mean spare time,
> either. This is stuff we'd be working on at the *office*. :) Seriously,
> compatibility between the PTK member model and our authentication/scaling
> needs is mucho important for our projects.
This would be just amazing. I _really_ want to move this user storage
and authentication stuff out of the PTK. If this proposed Product
materialises, it would be a huge win for all sorts of people, especially
once a few standard authenticators and stores are implemented. Opinion
totally unbacked by inside information (I live in Waterloo, after all): it
wouldn't be unlikely for this to be rolled in to Zope. In the meantime, I
have no problem assuming custodianship of it once it's been produced, if
you like.
Mike.
--
Mike Pelletier email: mike@digicool.com
Mild mannered software developer icq: 7127228
by day, super villain by night. phone: 519-884-2434