risc or cisc
robert.collins at canonical.com
Wed Apr 15 13:39:55 BST 2009
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
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.
> 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.
> These things may be worthwhile if an older server supports all the
> atomic operations, but has not yet handled the particular combination
> that the client wants to request. But is that really likely, or will
> new clients want to add entirely new concepts rather than just new
> arrangements of old ones.
I think there would be a steep curve before we started to benefit from
existing operations; like there has been with the network support at
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20090415/1f5356c8/attachment.pgp
More information about the bazaar