In message <[EMAIL PROTECTED]> on Tue, 04 Oct 2005 18:03:09 +0100, Bruce
Stephens <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
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
_______________________________________________
Monotone-devel mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/monotone-devel
