Re: [Monotone-devel] review of nvm.automate_out_of_band

[Thomas Keller]

Am 28.11.09 20:35, schrieb Timothy Brownawell:
> Thomas Keller wrote:
>> This is problematic because it would introduce "out-of-band" content /
>> chatter which we tell the user now that he can completly ignore (like
>> f.e. the netsync P() messages on remote_stdio connect). And of course
>> its a chicken-egg problem - we don't really want to allow any meaningful
>> non-stdio output and cannot tell the user the format's version without
>> using the format already. I'd probably vote for telling people to use
>> `au interface_version` directly w/o stdio and for not introducing yet
>> another (magic) versioning number. After all we can even return this
>> remotely with `au remote interface_version`, so it isn't even an issue
>> for `remote_stdio`.
> 
> The ignorable stuff is all on stderr, this would be on stdout like the
> rest of the actual interesting output (stdio packets). And the "without
> using the format already" is why it would be something simple like a
> leading <number> <whitespace> rather than a full stdio packet.

So something like

$ mtn au stdio
interface_version: 12.0

$

? We don't need a separate interface_version command available then, right?

>> Maybe we should just make two missing assumption hard facts now and
>> document them properly:
>>
>> 1) The command "automate interface_version" must never change its output
>> format.
>>
>> 2) Implementors of the "automate" interface should always call "automate
>> interface_version" in a non-stdio context, because the format of stdio
>> might be different.
>>
>> (We could go so far and make interface_version a CMD_AUTOMATE_NO_STDIO,
>> but since this hasn't been the case in the past, I wouldn't go so far.)
> 
> The whole idea of stdio is to not need to make multiple calls, so I'd
> think it makes sense to make sure any necessary versioning information
> is included instead of needing to be obtained separately.

Ok, then let us output it on stdio / remote_stdio startup on stdout. Are
you ok with the above format?

>>> we also need a "command_version command ..." that
>>> can list versions (including "does not exist") of specific automate
>>> commands, which is entirely unrelated to this discussion except that
>>> what it would print for "command_version stdio" is what I'm thinking
>>> stdio should start with.). 
>>
>> Nice in theory, but impractical, because we'd now not have to take care
>> about a single versioning, but multiple ones, one for every command.
>> This is already bad enough now, since we basically document everything
>> in three places, monotone.texi, the code comment above the actual
>> implementation and the interface version matrix I mentioned before. So
>> whatever new we come up with should be self-describing, machine-readable
>> and maybe even interface-complete (i.e. not only for a single command)
>> at the same time to make all three places where we document stuff right
>> now obsolete.
> 
> I'd think the version number could be put as an argument to
> CMD_AUTOMATE(), and then command_version would know how to look that up.

How would that exactly work? Would we just put in there the interface
version when the command last changed or how would we describe the
command's "history" otherwise?

> The comments above the code are basically redundant with what's in
> monotone.texi and can probably be dropped.
> 
> Having the individual commands versioned separately ought to make
> maintaining the compatibility matrix easier, since it could be scripted
> (spin through "mtn help automate" output, call command_version on each
> item with both old and new monotones).

Let us make this a later feature and not dependent on the landing of the
nvm.automate_out_of_band branch, ok?

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

signature.asc
Description: OpenPGP digital signature