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

[Bruce Stephens]

Hendrik Boom <address@hidden> writes:

[...]

> Would (multiple) front-end(s) and a shared engine library do?  It's
> possible you might get more efficient communications between the
> front and back ends that way.  And if you really want a pipe, one of
> the front ends could handle it.  Of course you'd end up having to
> worry about that drastic differences in the ways different OS's
> handle their shared libraries.

So you want to design a shared library API, instead?

I'd guess it's a little easier to engineer extensibility in a protocol
than a library, although both can be done to some extent.

I guess partly I'd fear that you'd end up with lots of little
applications linking with a shared library, and so there'd be a
significant danger that more than one would access a repository
simultaneously.  

On the other hand, the same sort of risk also applies to the proposed
architecture.  I guess a precondition for this kind of thing is proper
locking of repositories.


I think I'm imagining m7 (or something else) starting up the backend,
and that locking the database, then m7 does whatever it needs to do,
and then the backend exits, releasing its lock.  And simultaneously, I
can be using monotone.el, which (when necessary) fires up a backend
which takes a lock and releases it when it's done.

That doesn't seem ideal, so maybe this protocol wants to have a notion
of locking, so that an interface can group operations in suitable
chunks, and be assured that they're atomic.  But then that suggests a
need for transactions, so that an subpart can fail, unrolling the
parts that have already been done.  

Presumably that would be possible, at least for the operations that
only affect the database (since SQLite has transactional
functionality); I'm less sure about changes to the working tree.
Maybe that doesn't matter, though.  

I imagine that those operations which monotone now offers are almost
all the atomic operations that are needed, and that m7 just wants a
few more, and maybe they're easy to provide (because they're things
like committing and creating a new tag, which are database
operations)?


The shared library approach seems to work OK for subversion.  I
imagine that's because (often) you're using it to access a server over
protocol, and the server knows how to avoid breaking the database (by
serializing changes, or whatever)?

[...]