Just out of curiosity – where are you using Irmin? I'm curious to look at some real world code beyond the official examples and the merge-queues project.
I'm refactoring "Xenstore" (part of the control-plane for a Xen host) to use it. I want to make the server stateless so I can restart it if it crashes.. this mainly involves remembering lots of bits of state: connection information, watch registration, pending events etc. I also want to make it easier to debug while I'm at it.
I know it won't help, but I was thinking that one could keep hot backups by doing a fork() suspend() and then diffing the heap in realtime to migrate state between processes. Trying to keep state on the heap instead of the stack is a huge start. But this is stuff you already know.
Using process checkpointing is indeed one good way to implement fault tolerance. The Irmin style is more explicit -- the heap itself is tree structured, and the application uses it to checkpoint itself to disk/memory as a matter of course.
This ensures that only the minimal state required is stored (as opposed to the entire process heap), and also that state can be reconstructed intelligently to preserve sharing and special resources. For instance, file descriptors (if running in Unix mode) could be reified to a filename/offset and reopened, and memory mapped areas (such as the shared ring structures that Xen uses) could be re-granted from the hypervisor.
We've got an experimental IMAP server using Irmin as a maildir-replacement backend, to give us e-mail provenance and undo for when mass moves go horribly wrong. It's not quite ready for open-sourcing yet, but should be over the summer. I'm switching my personal e-mail over to it soon gulp
They are different design philosophies: Irmin is closer to "Sqlite-with-Git-instead-of-SQL", since it's just an OCaml library that lets you build graph-based datastructures that are persisted into memory or Git. Higher-level datastructures are built in the usual OCaml style on top of it.
You could build a Camlistore-like service on top of Irmin, but this design/eval hasn't happened yet to my knowledge. It's on the TODO list for Irmin applications -- while I really like Camlistore, I do also want finer control over routing of blobs in a content-addressed network to manage the physical placement of my personal data.
Another interesting aspect of Irmin is that the backend blob stores are also just another functor. In addition to the existing memory/HTTP-REST/Git backends, we've sketched out the design for a convergent-encrypted backend store as well. Other backends such as existing k/v stores like LevelDB or Arakoon shouldn't be difficult, and patches are welcome.
