[Twisted-Python] Do Viewables absolutely have to be return'ed by Avatars?
From some experimentation I find that the only way to make a Viewable get a meaningful perspective argument when executing view_* methods is to make sure that the references to that Viewable are given to clients as return values from perspective_* methods called on a pb.Avatar.
In particular, if the Avatar gives a client a reference to a Viewable by passing it as an argument to a remote_* method on the client, subsequent invocations of view_* methods by the client result in perspective argument in view_* methods being None. I have attached a complete working example of a client and server that succinctly illustrates this issue. Question: Is there a way to distribute un-asked for references to Viewables that properly get the perspective argument in their view_* methods? Sincerely, Daniel Sank
On Nov 20, 2013, at 3:54 PM, Daniel Sank <sank.daniel@gmail.com> wrote:
From some experimentation I find that the only way to make a Viewable get a meaningful perspective argument when executing view_* methods is to make sure that the references to that Viewable are given to clients as return values from perspective_* methods called on a pb.Avatar.
In particular, if the Avatar gives a client a reference to a Viewable by passing it as an argument to a remote_* method on the client, subsequent invocations of view_* methods by the client result in perspective argument in view_* methods being None.
I have attached a complete working example of a client and server that succinctly illustrates this issue.
Question: Is there a way to distribute un-asked for references to Viewables that properly get the perspective argument in their view_* methods?
So, this strikes me as incredibly subtle, and likely a bug, but the fix is not immediately obvious to me. Viewable objects are associated with their perspective when they are serialized. They are associated with the perspective which is serializing them. The "mind" object, passed by the client during the login process, can be just about anything - but one property that all "mind" objects share is that they are serialized *before authentication even occurs*, so there is no Avatar object and therefore no perspective around. Therefore the ViewPoint which gets stored in the remote reference cache will have a perspective of None, and all subsequent calls made to that reference will have no perspective. One way to fix this is to manually construct a ViewPoint rather than a Viewable and pass that to the client. But I do think that we should find a way to make your use-case work, to, or at the very least document the reasons why it doesn't in a comprehensible way... It's been a *very* long time since I took such a hard look at PB. Good catch! -glyph
Thanks much for the reply.
So, this strikes me as incredibly subtle, and likely a bug
Should I file a ticket?
One way to fix this is to manually construct a ViewPoint rather than a Viewable and pass that to the client.
If someone would be willing to supply a very simple demonstration of this I would appreciate it very much.
But I do think that we should find a way to make your use-case work, to, or at the very least document the reasons why it doesn't in a comprehensible way...
I am willing to help but as of right now I only know how to use perspective broker; I do not know how it works under the hood. I have been collecting notes on bugs in the perspective broker documentation. I promise to submit a documentation patch when I have a first draft of my project up and running. Regards, Daniel Sank
On Nov 22, 2013, at 12:01 PM, Daniel Sank <sank.daniel@gmail.com> wrote:
Thanks much for the reply.
So, this strikes me as incredibly subtle, and likely a bug
Should I file a ticket?
Absolutely.
One way to fix this is to manually construct a ViewPoint rather than a Viewable and pass that to the client.
If someone would be willing to supply a very simple demonstration of this I would appreciate it very much.
It's a very simple change to your server; your client remains the same. Just construct a ViewPoint with the user as perspective around your viewable.
But I do think that we should find a way to make your use-case work, to, or at the very least document the reasons why it doesn't in a comprehensible way...
I am willing to help but as of right now I only know how to use perspective broker; I do not know how it works under the hood.
Well, it's open source, so the hood opens right up, go ahead and pop it :-).
I have been collecting notes on bugs in the perspective broker documentation. I promise to submit a documentation patch when I have a first draft of my project up and running.
Please feel free to submit _many_ bugs, if there are many issues :-). -glyph
One way to fix this is to manually construct a ViewPoint rather than a Viewable and pass that to the client.
If someone would be willing to supply a very simple demonstration of this I would appreciate it very much.
It's a very simple change to your server; your client remains the same. Just construct a ViewPoint with the user as perspective around your viewable.
I just looked at the viewpoint api docs. I believe I understand. Thank you.
I am willing to help but as of right now I only know how to use perspective broker; I do not know how it works under the hood.
Well, it's open source, so the hood opens right up, go ahead and pop it :-).
Indeed I will do so. I just meant to indicate that as I have no prior experience with the source I cannot promise any sort of timeliness for a fix.
I have been collecting notes on bugs in the perspective broker documentation. I promise to submit a documentation patch when I have a first draft of my project up and running.
Please feel free to submit _many_ bugs, if there are many issues :-).
There are indeed many issues, however they are inter-related. As I said, I will try to make some sense out of what needs to be fixed and file (and fix!) tickets in as orderly a fashion as I can. -Daniel Sank
Question: Is there a way to distribute un-asked for references to Viewables that properly get the perspective argument in their view_* methods?
I think this is a pretty reasonable question but nobody's biting. Did I do something wrong in the way I asked?
On Nov 22, 2013, at 11:20 AM, Daniel Sank <sank.daniel@gmail.com> wrote:
Question: Is there a way to distribute un-asked for references to Viewables that properly get the perspective argument in their view_* methods?
I think this is a pretty reasonable question but nobody's biting. Did I do something wrong in the way I asked?
This is what I was trying to answer when I said to construct and return a ViewPoint explicitly instead of hoping that it gets implicitly associated through the process of serialization. If that's not the answer you were looking for, could you clarify the question? -glyph
Question: Is there a way to distribute un-asked for references to Viewables that properly get the perspective argument in their view_* methods?
I think this is a pretty reasonable question but nobody's biting. Did I do something wrong in the way I asked?
This is what I was trying to answer when I said to construct and return a ViewPoint explicitly instead of hoping that it gets implicitly associated through the process of serialization. If that's not the answer you were looking for, could you clarify the question?
You answered it for sure! The email in which I asked why nobody was biting was sent before anyone responded. Thanks again :) -Daniel
One way to fix this is to manually construct a ViewPoint rather than a Viewable and pass that to the client.
For the sake of trying to get my current project to work and so that I can understand what's really going on and fix the bugs in pb: how would I do the similar thing for a Cacheable? Looking at the source so far I'm having trouble figuring out where things like Viewable come into play.
On Dec 2, 2013, at 11:45 AM, Daniel Sank <sank.daniel@gmail.com> wrote:
One way to fix this is to manually construct a ViewPoint rather than a Viewable and pass that to the client.
For the sake of trying to get my current project to work and so that I can understand what's really going on and fix the bugs in pb: how would I do the similar thing for a Cacheable? Looking at the source so far I'm having trouble figuring out where things like Viewable come into play.
This isn't quite as clean as with ViewPoint, but it's not all that bad either. Basically, you need to inject the correct perspective into the RemoteCacheObserver which is constructed; unfortunately it reads it only from the jellier. So: fix the jellier :-). So something like this might do the trick: class Perspectiveize(Jellyable): def __init__(self, perspective, obj): self.perspective = perspective self.obj = obj def jellyFor(self, jellier): old = jellier.invoker.serializingPerspective jellier.invoker.serializingPerspective = self.perspective try: return self.obj.jellyFor(jellier) finally: jellier.invoker.serializingPerspective = old Untested, but I think it should do the trick. One caveat though; if the 'obj' (in your case, Cacheable) that you wrap with this is serialized twice within the same top-level call to 'jelly', (i.e. if there are multiple references to it from within a single return message or remote method call) the second time it is serialized, it will simply serialize a reference to the first; this means you have to be careful to be sure that the Perspectiveize object is serialized before the Cacheable itself if the Cacheable is to be serialized at all. Good luck, -glyph
class Perspectiveize(Jellyable): def __init__(self, perspective, obj): self.perspective = perspective self.obj = obj def jellyFor(self, jellier): old = jellier.invoker.serializingPerspective jellier.invoker.serializingPerspective = self.perspective try: return self.obj.jellyFor(jellier) finally: jellier.invoker.serializingPerspective = old
That did work, and it helped my understand a bit more about how pb works. Now that I have workarounds for the problems I had with pb I'd like to try to actually modify the source to make things easier. I still can't log into the website but as soon as that's fixed I'll get started filing tickets etc.
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). 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.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?
I'm posting this for future hapless n00bs like myself who find this thread while trying to grok perspective broker.
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).
By looking around in the source code and doing more experiments I have figured out that you can just do this mind.perspective = thePerspectiveIWantToAssociateWithThisMind All subsequent serializations of Viewables and Cacheables work exactly as they should. This seems like a totally reasonable and simple way to fix the issue presented at the start of this thread. Interestingly, this isn't explained in the howto, and seems to have been forgotten by the developers (or this is a bad solution for reasons I don't understand). When the website is working again I'll file a documentation ticket (and fix it).
On Dec 7, 2013, at 12:28 PM, Daniel Sank <sank.daniel@gmail.com> wrote:
I'm posting this for future hapless n00bs like myself who find this thread while trying to grok perspective broker.
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).
By looking around in the source code and doing more experiments I have figured out that you can just do this
mind.perspective = thePerspectiveIWantToAssociateWithThisMind
Oops, I wrote my previous reply without having seen this message! :-). And yes, I'd totally forgotten that that's a way to do it, because the documentation is horrible and it's been years since I worked on a PB-based application. I would strongly encourage you to contribute documentation enhancements that add the requisite level of docstring coverage to PB. Thanks for your interest so far. -glyph
I would strongly encourage you to contribute documentation enhancements that add the requisite level of docstring coverage to PB.
Eagerly awaiting for the website login to work so I can do that.
it's been years since I worked on a PB-based application.
I would like to know, is there anyone else who knows how pb works, or is it mostly just you (glyph)?
I would like to know, is there anyone else who knows how pb works, or is it mostly just you (glyph)?
I'm asking this just to get a feel for who's who among twisted developers, not for any other reason. To be clear your help has been awesome and I really appreciate it very much! :)
On Dec 8, 2013, at 7:56 AM, Daniel Sank <sank.daniel@gmail.com> wrote:
I would like to know, is there anyone else who knows how pb works, or is it mostly just you (glyph)?
I'm asking this just to get a feel for who's who among twisted developers, not for any other reason. To be clear your help has been awesome and I really appreciate it very much! :)
I'm sure that several other core developers understand how it works, but as long as I'm answering your questions promptly there's no reason for them to pop their heads in ;). -glyph
On Dec 8, 2013, at 7:46 AM, Daniel Sank <sank.daniel@gmail.com> wrote:
I would strongly encourage you to contribute documentation enhancements that add the requisite level of docstring coverage to PB.
Eagerly awaiting for the website login to work so I can do that.
What exactly is the problem with login? I skimmed another message where you complained, but then I tried to log in myself and it worked so I assumed the issue was temporary and had been fixed. -glyph
On Dec 7, 2013, at 9:30 AM, Daniel Sank <sank.daniel@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
I'm On Nov 21, 2013 7:56 AM, "Daniel Sank" <sank.daniel@gmail.com> wrote:
From some experimentation I find that the only way to make a Viewable get a meaningful perspective argument when executing view_* methods is to make sure that the references to that Viewable are given to clients as return values from perspective_* methods called on a pb.Avatar.
In particular, if the Avatar gives a client a reference to a Viewable by passing it as an argument to a remote_* method on the client, subsequent invocations of view_* methods by the client result in perspective argument in view_* methods being None.
I have attached a complete working example of a client and server that succinctly illustrates this issue.
Question: Is there a way to distribute un-asked for references to Viewables that properly get the perspective argument in their view_* methods?
Sincerely, Daniel Sank
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
participants (3)
-
Daniel Sank -
Glyph -
Wenxiang Wu