[Sugar-devel] [RFC] Better disk format for journal entries
michael at laptop.org
Sun Jun 27 12:10:30 EDT 2010
> On 27.06.2010, at 05:06, Michael Stone wrote:
>> 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.
>> A few days ago, I wrote a little bit about what I think such a format might
>> look like over here:
>> Unfortunately, this note didn't generate much of a response
> Duh! Who would have expected that the actual message went on below the
> top-reply and quote?
Only someone who knew me and my shy, tentative ways. :)
> I have simply not seen it. Even glancing over it now it did not read like an
> actual proposal.
That's because it was a musing, not a proposal.
>> -- thus, to whet
>> your appetite further, here's a (rough!) exporter from today's DS into the
>> format sketched in that note, available both in the the patch following this
>> note and in my combined sugar git repo  in the "xos" branch.
>> Already, I find it helpful both for browsing my DS with filesystem tools and
>> for resuming activities from the Terminal.
>> What cool things can you think of to do with it?
>> : Links to my sugar git repo:
> I like the directory layout. Could you explain why you see a need for the
> generality of a custom "./resume" script?
I chose this approach mainly, for the sake of encapsulation and ease-of-use
rather than for generality.
Here's what I mean:
a) if an activity session is represented as directory
then being focused on such a session corresponds to having a shell whose
current working directory is the dir in question:
~/Photos+of+Butterflies_1a21458b $ ...
b) if I want to resume the currently focused activity session dir, then there
are three basic things I can imagine doing:
1) exec "./resume"
2) exec "sugar-resume"
3) use IPC to tell some daemon to do one of the above.
(1) is nicely language-agnostic, direct, and easy to test in isolation of
other components. however, it is very opaque.
(2) imposes some helpful consistency on how resumes happen at the cost of
making it hard to experiment with new ways to implement resume.
(3) is, in my experience, a pain.
I picked (1) for my scheme because it seems better suited to my current
More information about the Sugar-devel