Re: [Monotone-devel] merging branch to allow 'automate stdio' over the network

[Timothy Brownawell]

Thomas Keller wrote:
> Thomas Keller schrieb:
>> Timothy Brownawell schrieb:
>>> Maybe it would be worthwhile to add an "automate remote <command>
>>> <args>" that would run a single automate command remotely and return
>>> the raw output (without the "automate stdio" packetization)?
>> This at least would allow us to easily create further "syntactic sugar"
>> custom commands via automate_lua.
> 
> I've implemented 'automate remote' in
> 7db60e9decd9ca1fa9f4c280b5c933d80bf7b24b in Timothy's branch.
> 
> A sample call looks like this:
> 
>   $ mtn au remote --remote-stdio-host host:port -- \
>       content_diff \
>       -r87162067ff644276a96f92302b5aa082d526b53f \
>       -rec8938265959026b5e76b0b608d7fda6190b1aa9 NEWS

Cool!

> There are a couple of rough edges, though:
> 
> 1) automate options are not parsed with our option machinery, because
> technically we have no idea what's a valid option server-side and what's
> not. Thus certain option syntaxes like "-d foo.mtn" or "--keydir bla"
> won't work - I always expect an option to start with -- or - and if
> there is an argument, it has to follow the option directly, i.e.
> "-dfoo.mtn" or "--keydir=bla". Server-side options have to be given
> after "--" in the command line, otherwise they're interpreted as local
> client options.

I don't think there's a good way to avoid this, because 'automate stdio'
expects to have its options already parsed out. So either 'automate
remote_stdio' would have to behave differently than 'automate stdio'
(very bad), or 'automate remote' and 'automate remote_stdio' would have
to look different on the wire (also bad, since now the server has to care).

> 2) The output of a single command is still stdio-encoded - while I could
>  use some custom condition in automate_session.cc, line 219ff, I'm
> rather for using automate_ostream there by default and pass a different
> ostream (with no stdio encoding) in there for the single-run case.

This is fixed now. It takes an automate_ostream, and there's a subclass
that doesn't do the packetization and demuxes the data between an output
and an error stream.

> 3) I haven't yet decided if / how output and especially errors from the
> client are distinguished from those from the server. F.e. I think server
> errors should lead to a client return code != 0, but higher ones than 1
> or 2 which are currently returned for user / option errors.

I have it exiting with code 1 and printing a message with the original
code, E(..., F("Received remote error code %d")).


Does anyone see any remaining issues that should be handled before merging?