[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] merging branch to allow 'automate stdio' over the n
Re: [Monotone-devel] merging branch to allow 'automate stdio' over the network
Thu, 08 Oct 2009 21:44:29 -0500
Mozilla-Thunderbird 126.96.36.199 (X11/20090701)
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
> 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?