Re: : capability to use @property for remote object

Thanks for your extended explanations and proposed workarounds.
They are helpful for me, for sure.

I will try to use them in my case.


-----Original Message-----
From: Irmen de Jong [mailto:irmen-qWit8jRvyhVmR6Xm/[email protected]] 
Sent: Tuesday, November 05, 2013 6:52 PM
To: [email protected]
Subject: Re: [Pyro] : capability to use @property for remote object

On 2013-11-05 15:09, Andreas Kostyrka wrote:
> Short answer: I don't think so. Happy to learn something else.

Indeed, Pyro4 does not provide remote attribute access. It only remotes method calls.


> Long answer: it's a hard problem, far from trivial.
> Basically, when you write obj.method() in Python, you are doing
> multiple things:
> 
> # that fetches the method and makes it into a bound method that knows
> that it's first parameter is obj
> _ = obj.method
> # now call the thing.
> 
> _()
> 
> Now how does the proxy object work? (that's just an educated
> guestimate, I didn't look at the source)
> 
> # fetch a RemoteCall object that knows what it's supposed to call
> 
> _ = proxy.method
> 
> # and now do the network traffic thing:
> _()
> 
> The biggie here is that at the time you do the attribute lookup, we
> don't know what the user will want to do with it.

In Pyro4 the object you are talking about is called _RemoteMethod but 
essentially the proxy works as you describe :)


> Now the reality is that it's kind of solvable if you are willing to
> add additional latency and/or some complexity to the code.
> 
>  Ideas for a solution would include:
> 
> 1.) trigger an attribute access remotely the same time you do it
> locally. If the result is callable, return the RemoteMethod instance.
> If it's not, try to serialize the value and send it back.
> 
> Disadvantages include doubled network latency.


This is what Pyro 3.x did to implement its remote attribute access. I 
didn't want to introduce the overhead and complexity again in Pyro4.


> 
> 2.) when creating the proxy, scan the remote object to see what
> descriptors are defined for the class. That should give at least
> sensible hints what attribute names need special care (see item 1)
> without causing additional latency for normal method calls.


Interestingly, this mechanism is actually on the TODO list ("metadata"). 
It could also provide information about oneway methods and other stuff.  
There has not been much demand for the feature so far. Possibly because 
the sensible workaround is not that bad: just use remote methods to 
obtain the properties you need (for instance by returning a dict or 
named tuple with all the properties at once. This performs better too.)


Regards
Irmen de Jong


------------------------------------------------------------------------------
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most 
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
_______________________________________________
Pyro-core mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/pyro-core

------------------------------------------------------------------------------
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most 
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk