Andreas Känner wrote:
Maybe someone from the core development team can explain how much work
it would be to build a libmonotone or a XML interface?
I'd really prefer not to make a libmonotone, for a few reasons:
- separate programs make it easier to debug. you can post to the
mailing list the exact input and output from monotone, and we can
add the case to a testsuite if it's a real bug.
- separate programs make it easier to make assumptions in monotone.
it has no provisions for multiple threads in it, for example, yet
it does things which might otherwise be considered unwelcome
(multiplexed network i/o, calling system() from lua to fire up a
merge client) with its calling thread.
- it makes it likely that one or other interface will be a second class
citizen (probably command line); I'd prefer to keep the command
line equally usable. emacs / vim / shell use of monotone will
invariably continue to need a powerful command line.
- it's GPL, so you can't link it into eclipse atm anyways. not sure
about xcode. maybe we could track down all the developers and
convince them to relicense, but it'd need to be for a compelling
reason.
- probably anyone wanting such a library would want it to be lowest
common denominator, which means C, so we'd have to rephrase a
certain amount of the entry points in monotone in terms of even
looser typing and weaker checking than we currently perform.
that said, we could go a ways towards making it more scripting-friendly.
I'm aware that the command line is still a bit unfriendly. the way I see
this problem, there are two sides to it:
- sometimes it's hard to parse the output from monotone.
- sometimes it's hard to formulate the input you want to feed to
monotone
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.
the latter problem I'm not sure is a real problem. I'd like to hear if
it is. it seems to me that *invoking* monotone via system() or execve()
is just as easy as any sort of libmonotone would be, and that the
majority of the problem people are perceiving is in parsing output. if
that's not true, it'd be good to know.