monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Monotone-devel] Re: automate stdio, really


From: Bruce Stephens
Subject: [Monotone-devel] Re: automate stdio, really
Date: Wed, 30 Aug 2006 20:02:48 +0100
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

Chad Walstrom <address@hidden> writes:

[...]

> Since we're revisiting it, I want to point out Graydon's reply
> regarding I/O formats:
>
> http://www.mail-archive.com/address@hidden/msg01927.html
>
> His opening sentence states it well:
>
>       "I understand your concern, but I think you're over-stating
>       the problem (or failing to note the slow direction we're
>       already moving in)."
>
> He covers the problems of different formats in depth, and then closes
> with:
>
>       "I can tell you what my preference is, though: I'd prefer if
>       the automate commands all pumped out basic_io stanzas. I'd
>       prefer if you could send basic_io stanzas to monotone as
>       command sequences (say, for monotone stdio). I'd prefer if all
>       commands could be invoked via stdio. And I'd prefer, rather
>       than per-command things like --brief, that we do what marcel
>       suggested (and what, if you look, the ROADMAP file has listed
>       for some time), and give lua hooks a chance to control output
>       formatting in general, so that if you *don't* want basic_io,
>       there's something simple and general you can do about it."
>
> So, yes.  Converging on basic_io and stdio is the "basic" idea. ;-)

OK, that seems potentially clean: the C++ core of monotone deals with
basic_io, and we have lua hooks that somehow convert from usable
command line parameters to basic_io input, and from basic_io output to
things useful for command line use, and perhaps separately for
shellscript use.

Obviously the default implementations need to provide something not
too far off the current non-automate behaviour.  (Graydon's also
commented that the basic command line ought to be usable, and not
require too much user scripting or a GUI to be useful.)




reply via email to

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