[Zope-PTK] Stability rule-of-thumb (fwd)

[Mike Pelletier]

On Fri, 4 Feb 2000, Phillip J. Eby wrote:

> >	listing valid users
> 
> In the UUF/PTK model, listing valid users is not a required interface,
> since it is inappropriate to use it for large databases.  The PTK really
> wants a list of registered Members, which is not the same thing as a list
> of everyone who can log in.  It's the responsibility of the UserSource to
> provide a UserFolder-style management interface, if one is desired.

    Thanks for reminding me... PTK issues asside, we had decided to make
some sort of listing interface a standard part of the API, though
optional.  Simply 'getUserNames' is enough for all purposes.  'getUsers'
can be built with that and getUser, however if 'getUsers' is made a
documented method as well, some implementations may be able to do it more
efficiently than map(getUser, getUserNames).

    I know that there are cases where these are very expensive operations.  
I would rather allow those cases to simply not implement this part of the
interface than not define it on the interface at all.  After all, these
are part of the BasicUserFolder interface, which we should make every
effort to support, at least in the best case.

> Again, we must distinguish between a Validator and a UserSource.  Radius
> and NDS would be either UserSources, or something a User object would talk
> to in order to implement authenticate().  Either way, they are not
> Validators.  I currently envision only three kinds of Validators:

    Hmm.  Does this mean that to support some schemes, you will need to
extend the User object?> 

> Repeat...  all a Validator does is parse data out of the REQUEST object,
> set cookies, etc.  It does not look up any data, as that is the job of the
> UserSource.  It does not actually authenticate the user, as that is the job
> of the UserSource.

    Question...  The UserSource is, naturally enough, the source of all
Users.  How does UserSource decide what class to make them?  Do I (as a
UUF installer) have any influence over what an arbitrary UserSource
returns as a User, or is it up to the UserSource author?  I think this was
covered, but I can't recall it...

    Perhaps the UUF itself should have as attribute 'UserClass' the User
class you wish to use.  Then getUser fetches it's four basic values and
returns self.UserClass(name,pw,domains,roles).  UserClass would likely
default to UniversalUser or some such thing.

    Better still, perhaps the UserSource should just return a tuple, which
UUF turns into a User.  That way there is less room for error from a
UserStore author.

Mike.

-- 
Mike Pelletier                          email: mike@digicool.com
Mild mannered software developer          icq: 7127228
by day, super villain by night.         phone: 519-884-2434