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

Stuart 'Zen' Bishop zen@cs.rmit.edu.au
Sun, 6 Feb 2000 14:06:19 +1100 (EST)


On Fri, 4 Feb 2000, Mike Pelletier wrote:

>     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.

getUserNames has to be there to support the Zope management interface
(eg. assigning a local role). Although this interface still works for
3000 users, I'm fairly certain I'm going to have to start patching it
to work with 40000...

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

It seems that way. Some problems GUF tried to solve (being able to
seperate the role membership, authentication, valid domains and 
now user properties) have now been pushed down to the user object.
The valid user list has been factored out into the UserSource.

There exists a need for all of these functions to be pluggable. 

If instead of a developer going and writing a UserDB like UserSource,
they instead wrote components that could be mixed and matched, more
people would benefit. 

    class UUFComponent(persistant):
	def authenticate(...)
	def roles(...)
	def domains(...)
	def setProperty(...)
	def getProperty(...)
	def listProperties(...)
	...

In the UUF, an administrator could dump arbitrary components. In the
UUF management panels, they would then select which UUFComponent handles
which functionality partition (the default being set to a builtin 
component, which simply stores the relevant information in the ZODB). 
In this way, one UserDBComponent object could handle the user properties 
and valid domains, a PAM object the authentication and the role membership 
stored locally in Zope.

A problem with this approach:
    It would be nifty if there was a usersWithRole method available
    (Its on my mind as I need this right now...) This could be done 
    efficiently if the getUserRoles method was guarenteed to be 
    implemented in the same component as the getUserNames()
    method. However, with the above aproach, it could not be assumed
    as these methods would definitly be in seperate functional partitions.

It would be nifty (but probably outside the scope of an initial release)
if multiple components could be selected as sources for the userproperties. 
In this way I could have multiple property sheets from different sources 
(possibly readonly). There would have to be a property sheet called 'default' 
which is read/write for applications such as PTK which need a 
backend-independant method of storing properties.

-- 
 ___
   //     Zen (alias Stuart Bishop)     Work: zen@cs.rmit.edu.au
  // E N  Senior Systems Alchemist      Play: zen@shangri-la.dropbear.id.au
 //__     Computer Science, RMIT 	 WWW: http://www.cs.rmit.edu.au/~zen