[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