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

[Timothy Brownawell]

Thomas Keller wrote:
> 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?

I suppose that could work, but I think it'd be better to have

$ mtn au stdio
2

$

with the "2" being specific to the stdio format rather than being the
full interface_version number. So it will tell you exactly whether you
can talk coherently to this particular monotone, and then later you can
call interface_version or command_version or whatever to see if you
agree on the availability and syntax of particular other commands. Using
the interface_version number here would bake in the issue of "inventory
changed formats and the major version incremented, and now viewmtn needs
to refuse to work until it's told about the new version".

>>>> 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?

Just a number that increments every time that particular command
changes. The full documentation (with change history) would still go in
monotone.texi.

>> 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?

Sure, I just think that the current changes should be something that
will still make sense after we get something more flexible than
interface_version.