Current: Reoccurring need exists, adult programmer maybe checks wiki for hints, uses command-line, then maybe blogs or wikis how-to hints.

State of art: Reoccurring need exists, adult checks AppStore, downloads App. Apps are hard to create, share, or modify (as are sugar Activities).

Future: Reoccurring need exists, kid tells Helpful Tool Bench, questions are asked, need met, questions become easier.

Incremental improvement of current:

* “maybe checks” – strengthen “of course I checked X first!” social focus (eg, AppStore).
* “wiki” – lower barrier of difficult unstructured unaided search experience. “I want to …” task oriented search. Clarifying “do you want Y or Z?” aids.
* “hints” – ease path for hint becoming script becoming curated and available ($ olpc-contrib3 –bobs-flickr-uploader help;) becoming polished becoming sugared gui. AppStore. And ideally, not resulting in rpm/AppStore/Activity “here’s a pile of discrete tools, choose one and read its docs”, but a much more fine-grained task-oriented environment. Though, python doesn’t make it easy.
* “command-line” – supportive IDE. Success when “why would you want to go down to the CLI level when you can simply do…?!?”.
* others…

Minor matter of developer resources, and incentives, and clarity of vision, and less crippling programming languages, and… opportunities for incremental improvement.

The long version is, as always, “it’s complicated, though in this case, the way forward is comparatively well described.”

In short, the recipe calls for two parts Journal redesign, one part data store replacement, and one part network redesign.

Links to some details:

* http://wiki.sugarlabs.org/go/Design_Team/Designs/Journal
* http://wiki.laptop.org/go/Journal2
* http://wiki.laptop.org/go/Olpcfs
* http://wiki.laptop.org/go/Network2

Questions?

http://wiki.sugarlabs.org/go/Development_Team/Datastore_Rewrite

What I think we should do, is to develop a nautilus/gio/fuse plugin that reads the metadata and exposes it in the filesystem.

Here is a FUSE plugin in C#:

http://git.sugarlabs.org/projects/fsgateway/repos/mainline

This would be a great addition to the OLPC builds with both GNOME and Sugar

And ended up using a stack of one-liners something very vaguely like… oh, this:
http://wiki.laptop.org/go/Talk:Release_notes/623 , and a perhaps more official one:
http://wiki.laptop.org/go/Sugar.datastore.datastore#How_do_I_get_command_line_access_to_the_files_in_my_DataStore.3F .
I wonder how many times people have rolled their own solutions to this one. :( I too then moved the copies to a normal linux box to use its file browser.

Though I’m usually a big fan of self-documenting file names and non-binary protocols, here the underlying problem seems not the datastore filename, but the lack of an Activity to easily do bulk examination and movement of one’s work. Journal was back then unusably poor at this use case. And apparently still is. Perhaps a new “artifact-centric view” App is needed to ‘get it right’? And worry about tweaking Journal later, as it’s already so heavily committed, and thus has conflicts of interest? Though, perhaps the functionality is already on the Journal todo bug list?

Architecture wise, it’s nice to keep unique identifiers simple, clean, and without additional semantics. Eg, numeric uids in an sql database – one could start overloading them with other information (eg, “blue-happy-widget-123″ instead of “123″), but this would complexify without helping with much. So in the datastore, is the path of minimum complexity considering them more like uids, or more like archival files which should be self describing? And if archival, a common means of description would be adding a .meta file… which the datastore likely already has… which brings us back to tools.