very simple datastore reimplementation

[Mikus Grinbergs]

> Opnions?  ( we get an useful replacement that lacks ... )


> - Support for mounting removable datastores. We have agreed on moving
> to just list the files in removable devices, without the DS having
> anything to do.

I heartily agree with the need for simplification here.  Please keep 
in mind that a removable device might have THOUSANDS of files on it.


It appears that a major problem with removable devices is "What if 
the device changed status while the XO was suspended?"  It defeats 
the purpose of 'resume in milliseconds' to go out and check the 
content of removable devices during 'resume'.

Let me suggest a two-tier 'explore-the-system' (i.e., on resume). 
The first tier brings the XO back to the state it was in when it was 
suspended.  If some operation cannot now be completed (because the 
device no longer responds), I would like to see an option presented 
to the user (abort vs. retry).  The "retry" choice would kick off 
the second tier, in which the XO re-establishes the status of all 
devices. Depending on what it found, the XO would allow the "retry", 
or would again ask the user (thus allowing the user time to plug the 
device back in).


> - Filtering by arbitrary metadata properties. If only the journal is
> allowed to execute find() calls, then we can restrict the properties
> that need to be stored in the index, gaining disk space and speed when
> searching. Do we really need this functionality?

When I first read a description of the Journal, I mentally 
familiarized myself with the concept ("instead of locating objects 
by means of their position in an access hierarchy, locate what you 
are looking for by employing 'filters' operating upon metadata 
associated with the objects").  So far, so good.

But then I tried actually using the Journal.  Perhaps because I am 
not a kid, I find its current characteristics more or less unusable. 
  For instance, order -- my memory is now so weak that I can't 
remember why I started Terminal last Monday, nor why I saw a need to 
start it again last Tuesday.  [And it bugs me that there is no 
simple 'touch' to reset the date of a Journal entry.]

Further, since most of the objects I access are on removable 
devices, they have been placed there by software other than OLPC 
activities -- meaning they DO NOT HAVE the metadata that would make 
Journal 'filters' efficient.  [The principal facility that I can 
think of that would help me would be "full text search".]

<< This brings up a philosophical point.  It can be important to a 
kid to __describe__ what he was doing (by filling in the 'Title' 
field in the Activity, and perhaps by adding tags to the Journal 
entry) -- this allows him to later *extract* that same Activity from 
all the things in the Journal.  But I myself *resent* having to take 
my attention away from what I am focused on, just to "fill in" a 
description to assist subsequent retrievals -- so I don't bother. >>

Also, in using Google I often "narrow down" my search by iterating 
'search within results' operations.  I have not yet learned how to 
"string together" the Journal 'filters', to achieve the same result.


In summary, I am concerned that by disallowing filtering (when using 
Journal) by arbitrary metadata properties, you will take away the 
freedom of __kids__ to explore/create "virtual database schemes".
I think 'flexibility' for the user is worth the performance penalty.


mikus