Hendrik Boom <[EMAIL PROTECTED]> 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)? [...] _______________________________________________ Monotone-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-devel
