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: Application Authorizer Identity[0] username, password servicenameA,perspectivenameA servicenameB,perspectivenameB ... Identity[1]... ServiceA servicename="A" PerspectiveA[0] name otherdata PerspectiveA[1].. ServiceB servicename="B" PerspectiveB[0] PerspectiveB[1].. If that were a graph, there'd also be arrows from Identity[0] to both PerspectiveA[0] and PerspectiveB[0]. 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 someone else. thanks, -Brian