risc or cisc

[Martin Pool]

2009/4/15 Robert Collins <robert.collins at canonical.com>:
> On Wed, 2009-04-15 at 22:26 +1000, Martin Pool wrote:
>
>> Well, you and Andrew probably know most about what would actually feel
>> right in the code as it currently exists.
>>
>> I do wonder though, how you would generate these calls in the client
>> code.  Generally the conversation with the server, whether that's one
>> RPC, several, or a composite, is going to happen within one call in to
>> the Remote* code on the client process.  Within the remote.py proxy
>> code, I suppose it could build up a data structure representing the
>> operations it wants to do and then send it - but is this really much
>> better than just sending a list of parameters, or maybe a dict of
>> parameters?
>
> The network structure and our local API's are essentially synchronised:
> its very hard to keep and maintain differences between them. A local api
> that is very chatty between two branches requires a network api that is
> very chatty between branches.

Right.  So if you have many fine-grained calls in the API, it will be
hard to avoid having so many round trips on the network.  The opposite
is possible though, to have high level calls in the client generate
multiple RPCs (which is what we're trying to get away from) or to have
them generate a compound RPC.  But I wonder if eventually even some
calls in the client would want to use a lazy evaluation or
minilanguage form, so rather than

  for i in repo.iter_some_thing():
    frob(i)

have

  repo.visit_some_things(frob)

so that it eventually sends across the network something like

 [visit_some_things, frob]

assuming it's smart enough to determine that at least part of frob is
better done on the server side.

>> In your example - is this any better than just sending
>> target.call('acquire_branch', t)?
>
> If we'd be happy having that in our local API, its not much different.
> But it is potentially easier to modify the minilanguage.

which might be what you meant.

(I don't mean this as a reason to avoid it, I'm just wondering what we
need to take full advantage.)

-- 
Martin <http://launchpad.net/~mbp/>