[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] merging branch to allow 'automate stdio' over the n
From: |
Thomas Keller |
Subject: |
Re: [Monotone-devel] merging branch to allow 'automate stdio' over the network |
Date: |
Sat, 10 Oct 2009 02:36:42 +0200 |
User-agent: |
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; de; rv:1.9.1.4pre) Gecko/20090915 Lightning/1.0pre Thunderbird/3.0b4 |
Am 09.10.09 04:44, schrieb Timothy Brownawell:
>> 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).
I think its a small problem actually and since you've documented it
well, its neglectable.
>> 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.
Very cool, thank you! All these streaming classes scare the hell out of
me, so I'm glad you did that :)
>> 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")).
Ok, this should be fine as well, thanks!
> Does anyone see any remaining issues that should be handled before merging?
The only remaining issue I see (but haven't quite tested right now) is
that --remote-stdio-host currently does not fallback on the default host
stored in the db, I'll look into this issue and do a couple of more
tests this weekend.
Thomas.
--
GPG-Key 0x160D1092 | address@hidden | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en