risc or cisc

Robert Collins 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
> 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.

> 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
Type: application/pgp-signature
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 mailing list