On Dec 7, 2013, at 9:30 AM, Daniel Sank <sank.dan...@gmail.com> wrote:
> Glyph, > > It seems to me that the right way to fix this issue with being able to > pass Cacheable and Viewable instances as arguments to mind.callRemote > methods would be to "attach" a perspective to that mind, possibly > during login (with a means for doing in manually as well). The mind might be any object, or it might be no object (i.e. None). This is confusingly documented, as remote_loginAnonymous is the only thing that explicitly spells it out, but given that it's a remote thing coming from the client, and no type-checking is performed, that's implicitly what it is. > As soon as > that though crossed my mind I remembered that I've seen "attach" and > "detach" floating around in the pb documentation as if it were once > upon a time a real part of the API, but sort of fizzled or was never > really adopted. This part of PB was removed many years ago, and references in the documentation ought to be removed as well. > I would appreciate your comment on this to help me > understand the state of pb and whether my idea of how to proceed is > correct? In the case where a 'mind' object has a callRemote method, it's one of two things: a RemoteReference or a RemoteCacheObserver. Both of these have a (public, given its name, but not super well documented) "perspective" attribute which triggers the serialization behavior you want when calling callRemote. So 'attaching' that perspective is as simple of setting the attribute. In your application, I think just setting that attribute is a much better idea than the craziness that I was suggesting with a custom Perspectivize class, and perhaps actually better than manually constructing a ViewPoint, since it generalizes completely to the whole serialization process. What's slightly more problematic is making this general. You have to fully deserialize the mind object before login, because it's explicitly provided in order to allow cred implementations to interact with the client during login. And since you don't know what the avatar is before it's time to log in, there's no way to deserialize it in this way! This is important if your Mind object were to be a custom Copyable that contained more than one RemoteReference, and, for example, had its own callRemote which could dispatch to different ones depending on what it's being asked to do. So how about this: Introduce a new custom interface, IHaveAPerspective (name intentionally terrible so I don't get hung up on naming it well); and then, in _cbLogin, do 'if IHaveAPerspective.providedBy(mind): mind.perspective = avatar'. (Be sure to get the right avatar, of course, the one before it's wrapped in an AsReferenceable.) If someone had a more elaborately constructed mind object than a RemoteReference, then they could implement the interface and write a property that set it on all the relevant references. Then, RemoteReference and RemoteCacheObserver can implement this new interface. For compatibility reasons, you might need to make this behavior disabled by default. But hey, it would be nice to have a public name for _PortalRoot rather than relying on adapter magic to construct one, so that new name could just do this by default. -glyph
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
