Re: [Monotone-devel] Re: Is there something like libmonotone?

[Nathaniel Smith]

On Fri, Jan 28, 2005 at 08:48:42PM -0500, graydon hoare wrote:
> the former problem I'd prefer to address by making all the output 
> functions in monotone invoke a lua hook when it's present. this way you 
> could redefine the output to look however you like, by providing an 
> extra lua file as a command line argument. if you wanted it to look like 
> xml, you could write hooks which dump out xml. none of my business.

Hmm, this sounds finicky and complicated to me too, and interacts
badly with, e.g., poeple's desire to have command-line verbosity
specifications (do they change the default hooks, or?).  I'm
especially not enthused about going through and coming up with the
proper function signatures for all the lua hooks we'd need, and then
having that be an external interface to support...

Most of the relevant commands are pretty trivial info-dumping things,
"heads" and "give me ancestry information" and "tell me about this
cert" etc., where most of the logic _is_ the the formatting.  What if
we added a subcommand family called something like "automate",
analogous to "db" or "list" -- so "monotone automate heads" just
prints the head revision ids one per line, no pretty-printing, no
sensitivity to --verbose, etc.  Maybe have a "monotone automate
version" that we increment when making incompatible changes to the
interface/output of "monotone automate" subcommands (which should be
relatively rare, since they wouldn't suffer the tension of also
wanting to be friendly to humans).  Have really stupid trivially
parseable output, like the heads example, or, say, dump graphs by
defining a format "everything to first whitespace is revision id of
one node; everything after it split on whitespace are its parent ids".

I can write a parser for this output format faster than I can figure
out the format of any XML data you care to name :-)

It can also be parsed with, like, cut(1) or awk(1), meaning we'd be at
the same time solving the "automate using klugy shell scripts" use
case, which is not sexy, but rather important.

If it turns out that exec() overhead is really bad, one could easily
add a streamlined version "monotone automate interact" or
something, where you feed in commands on standard input, get their
output out on stdout.

It also is very very easy to create and extend in an incremental way
-- "automate heads" would take about 10 lines of code to add, right
now, would be immediately useful, and could then be incrementally
improved.  Less so with a solution that involves designing XML schemas
or APIs.

You can also easily write a library in $YOUR_FAVORITE_LANGUAGE
wrapping this interface and providing whatever sort of interface seems
friendly in that language.  (Which is what all languages but one would
end up doing with a libmonotone anyway.)

How does that sound?  I don't want to be down on the idea of
automation, but it just seems to me like this would work out better
for everyone in the long run than some of the other ideas suggested...

Thoughts?

-- Nathaniel

-- 
.i dei jitfa fanmo xatra