[Sugar-devel] Hypothetical sugar-0.90 material, draft 1.

[NoiseEHC]

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
> <bmschwar at 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
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sugarlabs.org/archive/sugar-devel/attachments/20100610/5df05703/attachment-0001.htm