Irmin: Git-like distributed DB
mirage.io
mirage.io
[1] https://news.ycombinator.com/item?id=8053687
[2] https://github.com/mirage/irmin/blob/master/README.md#use-ca...
20:34 MST We are continuing to investigate a fileserver outage. Some repositories may be temporarily unavailable.
Pretty cool stuff. I am also working on a distributed database, https://github.com/amark/gun , that operates at the high level (web/javascript) rather than the low level. Although it looks like Irmin can be used in the browser? https://github.com/talex5/irmin-js ? Would love to hear some clarification.
I don't really understand the question about the stack. Where it belongs should only limited by its features.
It certainly can be used by people developing browser-based apps. For example, Cuekeeper [1] is a version-controlled TODO manager which uses Irmin. It's also been used with Xenstore [2], which is a different use-case (there are other examples in the readme of the Irmin repo).
- the browser, where some components of Irmin are transpiled to JavaScript using js_of_ocaml (http://ocsigen.org/js_of_ocaml/). Cuekeeper (http://roscidus.com/blog/blog/2015/04/28/cuekeeper-gitting-t...) is an interesting use-case for that.
- the kernel, where some components of Irmin can be compiled into a unikernel and be run on top of Xen/baremetal, bypassing the OS completely. Irmin-ARP (http://somerandomidiot.com/blog/2015/04/24/what-a-distribute...) is an interesting step is the direction of exposing kernel data and do interesting stuff with it.
My `irmin-js` experiment provides a Javascript API to Irmin, so you can write your application in Javascript too, rather than OCaml. My JS isn't very good though; here's what my example code ended up looking like:
https://github.com/talex5/irmin-js/blob/master/examples/test...
[1] https://github.com/ipfs/go-ipld [2] https://github.com/ipfs/notes/issues/40
Sure, conflicts need to be handled. That's a fundamental problem with reality!
For instance, a weakly consistent data structure could promise never to raise a merge conflict, and therefore be safe to compose. A stronger one could raise more precise merge exceptions depending on the exact error, which ripple up to the application.
An example of an application handling this sort of merge error is the Cuekeeper TODO manager (which is a pure JavaScript Irmin app that uses HTML5 Localstorage/IndexedDB). Try opening http://test.roscidus.com/CueKeeper/ in two tabs and creating conflicting changes, and see the Irmin merge error ripple up to the UI.
e.g. if you rename an action "orig" to "a" and to "b" and then merge, you'll end up with an action called "a" with a note saying the change to "b" was discarded.
BTW: it's easier to generate merge conflicts using this web interface, which lets you run two instances in one window:
http://roscidus.com/blog/blog/2015/04/28/cuekeeper-gitting-t...