Re: [Monotone-devel] Re: A Two-Fold Proposal: On Formats And Front-Ends

[Richard Levitte - VMS Whacker]

In message <address@hidden> on Tue, 04 Oct 2005 18:03:09 +0100, Bruce Stephens 
<address@hidden> said:

monotone> So you want to design a shared library API, instead?
monotone> 
monotone> I'd guess it's a little easier to engineer extensibility in
monotone> a protocol than a library, although both can be done to some
monotone> extent.

It's not really that hard to define an extensible API.  What we really
need is a few key items, of which one is an argument list structure.
In all cases, I'd suggest an API that forces a pattern like the
following:

  MTN_CTX *ctx = monotone_begin();      // Begin a session
  // ...
  monotone_do_operation(ctx, ...);      // Do one or more operations
  // ...
  monotone_end(&ctx);                   // End the session and free
                                        // the context pointer, which
                                        // is also reset to NULL.

As to how to define the rest of the API, and I can see one of the
following two models:

 1. a few well defined functions that take operation codes and lists
    of arguments
 2. a larger number of functions with specific arguments, which also
    take a list of optional arguments.

Cheers,
Richard

P.S.  Honestly, I'm not too keen on the shared library approach.  It
      comes with it's own set of problems that are sometimes very hard
      to resolve.

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

-- 
Richard Levitte                         address@hidden
                                        http://richard.levitte.org/

"When I became a man I put away childish things, including
 the fear of childishness and the desire to be very grown up."
                                                -- C.S. Lewis