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

[Matt Lavin]

I have never contributed to this mailing list before but I have been 
lurking for quite a while now.  I'd like to start by saying that I 
appreciate the work done on Monotone and I think that it has a great 
basis for success.  Making a libmonotone is something that I have 
desired for a long time and even started the process of figuring out how 
much work would need to be done to make it happen.  If I didn't have a 
day job I'd probably have already done it =).  See comments below.

Nathaniel Smith wrote:

> On Thu, Jan 27, 2005 at 01:01:56PM -0600, Matthew A. Nicholson wrote:
>  
>
> > Andreas K?nner wrote:
> >    
> >
> > > is there something like libmonotone? Just in case someone want to write 
> > > a  GUI on top of monotone...
> > >      
> > I don't think there is a libmonotone, but there should be...
> >    
>
> This is actually a matter of debate :-) In particular, graydon has
> pointed out that you really _want_ monotone to be a monolithic program
> with an extremely limited and well-defined interface to the rest of
> the world, because monotone is the only program we trust to manage
> your database without screwing things up.  (we have enough trouble
> making sure monotone won't screw things up in the first place...)
>  
I don't think that monotone has to be a monolithic (command line) 
program to ensure the security that you are referring to.  The library 
interface could provide an equivalent interface to the current command 
line.  I don't think that the original suggestion was to make ALL of 
monotones implementation details available in the library.

> This does leave open the possibility of wrapping a library around it,
> with some carefully designed interface, but since this interface
> wouldn't be much lower-level than the current command-line interface,
> and since the command-line interface is accessible from all languages
> (not just C++), my suggestion would be to improve the command-line
> interface's support for automation.
>  
There are many reasons why wrapping a command line program to make a 
library are not as good as a regular library.   A significant portion of 
the wrapping involves text processing, which is slow and buggy.  Any 
slight change in the output can cause problems that are not immediately 
noticeable.  A library interface would make it nearly trivial to add IDE 
integration to monotone ( I could almost guarantee that I would write an 
Eclipse plugin for it within a week ).  Another issue with command line 
parsing and complex scripting is that the output desired by the scripts 
is probably not the same as the output desired by a human.  The library 
interfaces allows programming languages to use monotone at a level that 
makes sense for programming and frees the monotone executable to provide 
a good user interface without concern for scriptablity. 

> There's definitely a lot that could happen to make monotone more
> scriptable, and I think we definitely should; I figure the best way to
> accomplish that is to wait for people who want to script monotone,
> then extend it in whatever ways they turn out to need...
>
> -- Nathaniel
>
>