monotone-devel
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]