Rhizome over git (PoC)

[®om]

Hi,

We discussed a little about Rhizome here, among other the idea to reuse some git principles for the Rhizome store.

There are several reasons:

• it would be better to store files in filesystem instead of sqlite db (performances and locks);
• we could imagine graphs of bundles (with parent relationships), potentially useful for a µ-blogging service for example;
• maybe it would allow improved sync between remotes;
• …

Today, I explored a little the idea of not only reuse the principles, but directly use git plumbing commands, only for storing data (not for sync or relationships).
I wrote a bash wrapper to provide main Rhizome store commands. This is a PoC, only intended to be executed on a computer.

A manifest is a git blob, containing key/value String pairs.
A payload is also a git blob, referenced by manifest.payload (but git does not "understand" this relationship).
A bundle is a git tag referencing a manifest blob (so users can modify a bundle while keeping the same bundle key).
The payload is also referenced by a git tag, not to be deleted by "git gc".

It is available here (rog means "Rhizome Over Git"):
https://github.com/rom1v/rogpoc

Here is a batch of commands (execute 1 by 1 to understand what happens) you can try:

git clone https://github.com/rom1v/rogpoc.git
cd rogpoc
./rog create meshms 111 222 <<< 'How are you?'
echo 'Fine, thank you' > /tmp/answer
./rog create meshms 222 111 /tmp/answer
printf '#!/bin/bash\necho hello\n' | ./rog create file '' 222
./rog list
./rog list meshms
./rog list '' '' 222
./rog list meshms '' 222
bid="$(./rog list meshms 111 222 | grep -o '^[^:]\+')"
./rog manifest "$bid"
./rog payload "$bid"
./rog update "$bid" <<< 'I changed my message'
./rog manifest "$bid"
./rog payload "$bid"
./rog delete "$bid"
./rog list

The advantages of git in my PoC is the hash-oriented storage and the packing and compression.
But I must admin these advantages are quite low: the hash-oriented storage can be implemented from scratch with little efforts. I use only a very little part of git here.

I don't use any "tree" or "commit" objects (because I felt it was a bit overkill).
However, another possible design could be:

• 1 bundle = 1 tag
• 1 bundle version = 1 commit
• 1 commit is 1 tree
• 1 tree is 2 blobs (a manifest and a payload)

But it adds a lot of useless indirections for a Rhizome store.
Maybe "commits" could be useful for parent relationships, but git is really designed for VCS (for example a commit has author/committer, nothing else, which is not very suitable).

®om

[Paul Gardner-Stephen]

Good work and very interesting ...

I am sure Jeremy will have some input when he takes a look.

Paul.

®om

--
You received this message because you are subscribed to the Google Groups "Serval Project Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to serval-project-dev...@googlegroups.com.
To post to this group, send email to serval-proje...@googlegroups.com.
Visit this group at http://groups.google.com/group/serval-project-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.