very simple datastore reimplementation
mikus at bga.com
Wed May 7 11:04:43 EDT 2008
> 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.
More information about the Devel