<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-2" http-equiv="Content-Type"> <title></title> </head> <body bgcolor="#ffffff" text="#000000"> 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: <a href="http://developer.android.com/guide/topics/data/backup.html">http://developer.android.com/guide/topics/data/backup.html</a> 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: <a href="http://developer.android.com/guide/topics/search/adding-recent-query-suggestions.html">http://developer.android.com/guide/topics/search/adding-recent-query-suggestions.html</a> 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: <a href="http://developer.android.com/guide/topics/providers/content-providers.html">http://developer.android.com/guide/topics/providers/content-providers.html</a> 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: <a href="http://developer.android.com/guide/topics/appwidgets/index.html">http://developer.android.com/guide/topics/appwidgets/index.html</a> 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: <blockquote cite="mid:AANLkTiny_GN-_EFxU8KbqYny0vVoJnVCBzOaQAQl9EFr@mail.gmail.com" type="cite"> <pre wrap="">On Thu, Jun 10, 2010 at 1:41 PM, Benjamin M. Schwartz <a class="moz-txt-link-rfc2396E" href="mailto:bmschwar@fas.harvard.edu"><bmschwar@fas.harvard.edu></a> wrote: </pre> <blockquote type="cite"> <blockquote type="cite"> <pre wrap=""> - 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. </pre> </blockquote> <pre wrap="">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 </pre> </blockquote> <pre wrap=""> 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. </pre> <blockquote type="cite"> <pre wrap="">even just a list of use cases that you believe have been overlooked. </pre> </blockquote> <pre wrap=""> 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 </pre> <blockquote type="cite"> <pre wrap="">Do you think our current datastore meets your criteria? </pre> </blockquote> <pre wrap=""> 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 <a class="moz-txt-link-freetext" href="http://git.sugarlabs.org/projects/versionsupport-project/repos/mainline/blobs/master/datastore-redesign.html">http://git.sugarlabs.org/projects/versionsupport-project/repos/mainline/blobs/master/datastore-redesign.html</a> 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 </pre> </blockquote> </body> </html>