Excerpts from Michael Stone's message of Sun Jun 27 05:06:31 +0200 2010: > I've longed, for quite some time, for an encoding of Sugar's journal entries > that is more amenable to manipulation with standard Linux tools and APIs. I've > also longed for a format that is friendly to rainbow and which can encode both > the data necessary for today's journal as well as the data necessary for > Eben's > Journal redesign mockups. If we are to introduce a new transport format for Journal entries, I'd much rather have us try to use one that's interoperable with other software. During past discussions on this list a few candidates were named (I don't have references handy, but the list archives should help locating them).
As for changes to the data model: While the Journal obviously needs to change, I believe the current data store to be generic enough to store anything we're going to need for now. The object ids are globally unique and can thus be used for inter-object references. Actions can be stored in metadata-only entries. BTW: Can anyone provide me with a JEB (Journal Entry Bundle) that was created by existing software? I've changed Sugar to support multi-entry bundles (for high-level backups) and would like to verify existing ones still work. > Already, I find it helpful both for browsing my DS with filesystem tools and > for resuming activities from the Terminal. You might find datastore-fuse [1] useful as well. It's still experimental, but works well enough that I use it for transferring attachments from my MUA directly to the data store / Journal (which I use for managing photos besides other things). While it's still rather basic, it provides access to the full data store content (including metadata as extended attributes) with full read/write/delete support (data+metadata). > What cool things can you think of to do with it? > [1]: Links to my sugar git repo: > > http://dev.laptop.org/git/users/mstone/sugar/commit/?h=xos > http://dev.laptop.org/git/users/mstone/sugar/snapshot/sugar-xos.tar.gz > git://dev.laptop.org/users/mstone/sugar Could you be convinced to move your repositories to (or duplicate them on) git.sugarlabs.org? The advantage of the latter is that anyone could "clone" your repo(s) and thus get a public repository they can push to. (*) Creating the project and cloning it require using the web interface, but those are just one-time actions - the repositories themselves are regular git repos accessible via ssh, so they don't get into the way of everyday work. Sascha (*) This is also half of an answer to your mail re. rainbow patches: My repo is on my home server which only has a public IPv6 address, not an IPv4 one. I don't want to create a rainbow project on git.sugarlabs.org myself because it might look like the "official" one. [1] http://git.sugarlabs.org/projects/datastore-fuse
signature.asc
Description: PGP signature
_______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel