[Twisted-Python] Perspective / Client confusion

Patrick K. O'Brien pobrien at orbtech.com
Thu May 29 20:03:22 EDT 2003

On Thursday 29 May 2003 03:37 pm, Glyph Lefkowitz wrote:
> On Thursday, May 29, 2003, at 10:31 AM, Patrick K. O'Brien wrote:
> > Since I'm using PyPerSyst to persist all the application data, I could
> > also
> > store user information there and use that to determine what a user
> > can/cannot
> > do, rather than rely on Perspectives.  But I'm not sure that is the
> > right
> > approach.  Any help would be greatly appreciated.
> Perspective is a very simple concept, with an almost-equally-simple
> representation.  It just means "a token representing the user's
> presence and permissions within the context of a particular service".
> So, you should be able to use PyPerSyst to store Perspective subclass
> instances as the "user information" that you want to keep in your
> application.

Itamar helped me a bit on #twisted, but I'm still a bit unsure of myself.  The 
problem seems to be that there are a number of different ways to do 
everything, and it isn't entirely clear to me how to evaluate the options.  
For example, I need more than one Perspective subclass.  And I'd like the 
same person (Identity) to be able to log into the application with whichever 
Perspective is available to them.

Itamar suggested that the best approach would be to have one service, several 
Perspective subclasses, and one Perspective instance for each client.  So now 
I think I need to override the service.createPerspective() to create the 
right kind of Perspective instance, or create the Perspective independently 
and then send it to service.addPerspective().  It also seems to me that I 
should hide the Perspective details such that when a user logs in they simply 
choose which of their perspectives they want to use (admin, user, customer, 
for example).  It also seems to me that I should generate the perspective 
names automatically, in order to keep them unique within the service 
(something like identity.name + perspective.__class__.__name__, perhaps).

If I'm going to persist identities and perspectives using PyPerSyst, I also 
need to be careful what references those objects contain, such as 
perspective.service and service.authorizer.  I'm not sure I want those 
persisted, so I probably need to add __getstate__ and __setstate__ methods to 
my subclasses.  I also need a way to load persistent indentities and 
perspectives from PyPerSyst when the application starts.  I know I've seen 
mention of those "load" methods, but I couldn't find any code examples.

I also need to figure out how to allow someone to create new identities and 
perspectives in the first place.  So I probably need to have the app start 
with a "root" type user/perspective that has the authority to create new 
identities and perspectives.  Maybe I need another Perspective subclass that 
deals only with that capability.

Am I making this more complicated than it needs to be?  I'd love to hear 
someone say "yes" and then show me a simple way.  It seems like what I'm 
trying to do would be pretty common for anyone creating a PB application that 
had many users that needed to be divided into groups, with each group having 
different capabilities.  The plumbing all seems to be there (Identity, 
Perspective, Service, Authorizer, etc.), but hooking everything together 
still eludes me.

Patrick K. O'Brien
Orbtech      http://www.orbtech.com/web/pobrien
"Your source for Python programming expertise."

More information about the Twisted-Python mailing list