[Twisted-Python] Perspective vs. Identity question
warner at lothar.com
Sun Sep 15 08:42:31 EDT 2002
> sounds like you are on the right track. For another example, take a look at
> twisted.enterprise.dbcred. It has two authorizers that create perspective
> and identities from a relational database and a "reflector" which is another
> type of data source.
Thanks for the confirmation. This stuff is finally starting to make sense.
You're right, dbcred is a good example. SQL is still pretty foreign to me,
but somehow seeing the SQL tables and the way dbcred is accessing them helps
me grok the identity/perspective stuff better. The fact that it's a different
style (building Identities on the fly rather than having them pre-built)
helps a lot.
So.. the Identity doesn't really have to exist before the call to
.getIdentityRequest().. it might be pre-made, or pulled out of a database by
name (or other persistent structure), or created with data retrieved from a
third party, or just faked altogether (like a chat service that lets anybody
log in, .getIdentityRequest() could just make a new Identity for every
caller, maybe enforcing unique names).
And the same is true for the Perspectives? .getPerspectiveRequest() could
retrieve an existing Perspective or create a new one on demand? I guess if
the perspective is supposed to hang around (like, um, say a chat service that
remembers user state between logins) then it shouldn't get deleted from the
service when the .detach() method is called. Ah, but it could get saved to
disk and then dropped from memory. And then reloaded when they log in again.
Hence .cachePerspective() and friend. Enlightenment dawns.
I keep coming up with more questions, but the process of phrasing the
question in a concrete manner is letting me figure out the answer without
asking it. Interesting. I think that means I'm past some inflection point.
Last rhetorical question (which I ask so that someone can tell me if I'm
wrong). There should be a roughly one-to-one correspondence between
perspective subclasses and service subclasses, right? Each service's
.getPerspectiveNamed method will create arbitrarily many Perspective objects,
with different names, for different Identities, but (generally) always of the
same class? MyFooService will have a bunch of instances of MyFooPerspective,
etc? The hierarchy looks something like:
If that were a graph, there'd also be arrows from Identity to both
PerspectiveA and PerspectiveB.
Ok, that's as much enlightenment as I can take for one day. Somebody tell me
if I got it confused. I'll try to write this up somehow so it might help
More information about the Twisted-Python