journal spec?

[Joshua N Pritikin]

On Sun, Dec 17, 2006 at 12:13:46PM +0100, Marco Pesenti Gritti wrote:
> MBurns wrote:
> >On 12/17/06, *Joshua N Pritikin* <jpritikin at pobox.com 
> ><mailto:jpritikin at pobox.com>> wrote:
> >    Can somebody give me a link to the mailing list archive where this
> >    discussion took place?
> 
> The journal user experience has been discussed in several meetings, but 
> not on the mailing lists. There is a section about it on the journal 
> which I assume will be filled once the plan is finalized.
> 
> http://wiki.laptop.org/go/OLPC_Human_Interface_Guidelines/The_Laptop_Experience/The_Journal

Yah, I read that already.

> Current implementation is just a prototype which will allow us to start 
> working on the UI. The API looks like:
> 
> ds = datastore.get_instance()
> obj1 = ds.get(<uid>)
> obj1.set_data(<array of bytes, or a string>)
> obj1.set_properties({'foo': 1, 'bar': 'bobloblawslawblog'})
> print obj1.get_properties()
> obj2 = ds.create(<array of bytes, or a string>, {'baz': 2134512})
> obj2.connect('updated', object_updated_cb)
> 
> Ivan is working on the real implementation. I don't know if he has any 
> specification about it nor I'm aware of public discussion.

I don't know what has been discussed so I'll just blurt out my idea. 
Based on the description of the Journal in the HIG, it seemed like GIT 
would be a close fit for the database requirements. Then new development 
would be limited to putting a pretty face on GIT, that is, something 
even simpler than gitk.

I'll just go through the HIG page point-by-point:

+ The Notion of "Keeping", No more "open" and "save"...

A commit in GIT is about as lightweight as you can get in terms of 
saving.

+ Temporal Organization
  Timeline...

The GIT database is organized temporally as long as you don't merge 
changes from friends. Maybe there should not be too much GUI support 
for merging in the first version because it gets so complex. Resolving 
merge conflicts in an XML document is not something that kids are going 
to readily understand without a lot of GUI support.

+ Level of detail...
+ Granularity...

Some additional OLPC structure could be added to the commit message to 
indicate the type of commit (level of detail), or maybe tags are enough.

+ Falloff... 

Not sure what this means.

+ A Typical Journal Entry
+ Implicit...

Means what? Autosave?

+ Explicit... 

Maybe your project has reached a milestone and you want to type in a 
description of the state of the project. GIT might support this with a 
tag.

+ The Power of Metadata
+ Implicit...
+ Ratings...
+ Use frequency... 

Not sure what is meant here. Of course the GIT database is immutable so 
these features might be better implemented outside of GIT.

+ Powerful Filtered Searching & Sorting
+ Filtering...
+ Sorting...

Of course GIT excels here. We just need to prod activities into 
storing uncompressed state because GIT will handle the delta compression 
and searching.

+ Special filters, labels or tags: about to be removed, lazy deleted 
+ (trash can), in progress...

Sounds like GIT branches.

+ Implicit Versioning System
+ Automatic, incremental saves...
+ Viewing revision history... 

Is it just me or is this reminiscent of GIT?

+ Automatic Backup and Restore
+ Automatic backups to server...

Simplified configuration for "git push / git fetch"

+ Full restore (temporal)...

GUI suger for "git reset --hard"

+ Partial restore(by object)...

GUI suger for "git checkout"

+ Temporary restore... 

GUI suger for "git checkout -b"

+ The Journal as a Progress Indicator
+ Two stages for entries...

Hrm, means what?

Not only do the requirements match pretty well but intuitively it makes 
sense for the OLPC platform. There is a "show the code" button on the 
keyboard. Kids should be introduced to distributed version control 
because that's how code development is organized.

Lastly, I'll just sketch out an example directory layout for an Abiword 
document:

./.git
./abiword/document
./bulletinboard/local-markup  # entries made on the local machine
./bulletinboard/net-markup    # entries made by friends
./suger/activities  # Which activities (& versions) were involved in 
                    # making this snapshot
./suger/members     # Who was invited to this activity?