risc or cisc

Martin Pool mbp at sourcefrog.net
Wed Apr 15 13:26:09 BST 2009


2009/4/15 Robert Collins <robert.collins at canonical.com>:
> I'm wondering whether it makes sense to just have very long parameter
> lists - e.g. 'make or open a branch at transport t, stacked if needed,
> of format Y, allowing shared, ...', (e.g. adding very high level
> operations), or to look at having a mini language that can operate on
> the server (e.g. if it was python:
> def acquire_branch():
>   try:
>       b = branch.open(t)
>   except NoBranch:
>       b = create_branch(t)
>       b.set_stacking()
>   return b
> b = target.run_script(acquire_branch)
> )
>
> I think a mini language is definitely more complex *today* but we're
> adding more and more methods - and the complexity of creating good
> abstractions is getting higher and higher.

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?

In your example - is this any better than just sending
target.call('acquire_branch', t)?

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.

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



More information about the bazaar mailing list