It seems that I cannot stop myself killing some kittens:
As I see the problem is that the DS wants to solve a lot of problems in
a general way. I think that this is simply impossible. A lot of
companies tried to create some general storage abstraction other that
files, but all of them failed (even M$ tried that for decades...). My
prophecy is that you will fail as well.
Another way to solve those problems would be to have every activity have
its own journal with its own user interface.
The activity then could use plain files for storage or an SQLite
database or just append a text file. The point is that the storage would
be activity specific, with activity dependent optimizations if necessary.
The activity would also show a list of existing documents/objects when
started and have a New... button to start a fresh one. It would also
eliminate the troubled activity start mechanic from the activity ring.
Of course SUGAR should have some very good library support to enable
creating the default DS user interface in several lines of code. Of
course for activities which does not save objects this would be optional.
Now because the DS storage would be scattered between activities, they
should have to implement a backup/restore API, lets call it BackupAgent:
http://developer.android.com/guide/topics/data/backup.html
A simple activity could just mention in the MANIFEST that it has a data
directory to be backed up and that would be all.
Of course the user should be able to use full text search so there
should be a either a central index or the activities should implement a
search API, lets call it SearchRecentSuggestionsProvider:
http://developer.android.com/guide/topics/search/adding-recent-query-suggestions.html
Of course SUGAR should have library support to ease creating this search
functionality.
Now to allow activities to share data they should implement some API to
be able to provide content to other activities, lets call it
ContentProvider:
http://developer.android.com/guide/topics/providers/content-providers.html
Of course a flag in the MANIFEST could just allow SUGAR to index the
data automatically.
It would need some primitive OLE (Object Linking and Embedding)
capability which is currently missing from SUGAR, lets call it
AppWidgetProvider:
http://developer.android.com/guide/topics/appwidgets/index.html
The remaining piece would be a dead simple Journal which would just list
the recently launched activities.
Now why would it be cool?
1. Searching among contacts, mp3 albums and picture bundles can be
totally different from the end user perspective.
2. It can be efficient, does not need copying large amounts of data.
3. Activities could be launched from GNOME.
4. It could be backwards compatible (if the APIs are set in stone).
5. The "DS" code (the library) could be developed when there is a need
in an activity, there is no need to redesign the whole thing over and
over again.
6. And I am sure that I could find some more...
Why it is just a pipe dream?
1. Python does not have anything like the DALVIK virtual machine so
every Python process consumes a lot of memory. Because of this,
implementing the above infrastructure would consume all available RAM
and so would not work. Of course the DS part could be C++ code as well
but unfortunately children could not look at the source.
2. It is already implemented so why bother?
Now, you should not take this message too seriously but you could
seriously consider a per activity DS if you have some free time.
Martin Langhoff wrote:
On Thu, Jun 10, 2010 at 1:41 PM, Benjamin M. Schwartz
<bmsch...@fas.harvard.edu> wrote:
- Reworking the datastore... while I welcome efforts in a new
datastore... _every Sugar release has a new DS implementation_ and
they get little testing and I've seen extremely light thinking about
what is _actually_ needed.
That's a very polite way of saying that you disagree with the extensive
thinking that's been done about datastore design and implementation for
No. _It says exactly what it says_. People have been thinking lots
about the fun part of the problem, thinking superficially about what
they'll have fun implementing. Not about the complete problem space.
Not about what hits users. Not about what we need for a saner
implementation.
even just a list of use cases that you believe have been
overlooked.
Ah...
- ENOSPC?
- Backwards compatibility? (Horrendously broken ATM on 0.84 -- I have
a bad patch for that...)
- Integration with GNOME? (for those "dual desktop" OS builds)
- Some reasonable degree of atomicity?
- Sensible backup/restore?
- Smarter handling of "bundle" filetypes...
= so together with the Journal, it can expose the many images or
videos in a 'Record'
= so the Record "file format" gets untangled
- Re-thinking of the Journal / Datastore interactions to access the
normal filesystem so that Gnome's ~/Documents directory can be browsed
- Working gracefully with large files
Do you think our current datastore meets your criteria?
No. It has heaps of problems.
And I love some the cool ideas (git-like smarts for example). But
_first_ DS has to shed its current stupidities. Talk of a rewrite that
lists cool ideas but none of the big gaps gives me the CADT shakes.
Just in case, I am taking
http://git.sugarlabs.org/projects/versionsupport-project/repos/mainline/blobs/master/datastore-redesign.html
to be Sascha's plan. Hope that's the right one.
Hate to sound so cranky, and I honestly like a VCS-styled Journal/DS.
But there are many hard problems to solve in the Journal/DS, and many
added hard problems that come with the VCS. Ignoring the hard problems
and charging with the features won't help a bit.
cheers,
m
_______________________________________________
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
