[Twisted-Python] Perspective / Client confusion
Patrick K. O'Brien
pobrien at orbtech.com
Thu May 29 18:03:22 MDT 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