Re: : capability to use @property for remote object

On 05/11/13 17:52, Irmen de Jong wrote:
> 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.)

Hi,
Actually, here we use Pyro, and we have a fork mainly to address this
need: https://github.com/delmic/Pyro4

However, I'm not really happy with the current implementation, so I'd
not advise to jump use it. For now it provides a couple of things:
 * When you get a proxy, the proxy comes with a list of oneway methods,
and attributes that must be available remotely. So the client doesn't
need to know the nitty-gritty details of each objects it asks for.
 * We have a sub-decorator of property, @roattribute, which is an
attribute that can only be read. These are efficiently proxy'd by
copying their values at initialisation (=pickle time).
 * We have a special type of object (with a special proxy) which has a
.value attribute which is always read and written via remote calls.


But, as I said, I'm not happy with that. IMO, it's still too much work
for the server and client programmers compared to a normal Python code.
My dream Pyro would introduce just one small requirement compared to
normal Python code: once an object is shared remotely, it cannot switch
an attribute type between method and object. Everything is else would be
handled by Pyro. On the first time an attribute is accessed (get) on a
proxy, it would check on the remote object what type it is, and then
keep this answer in cache. Probably you can also fill this cache at
pickle time, to avoid most of the overhead.

That were my 2 cents ;-)
Éric


------------------------------------------------------------------------------
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