very simple datastore reimplementation

[Eben Eliason]

On Wed, May 7, 2008 at 11:04 AM, Mikus Grinbergs <mikus at bga.com> wrote:
> > 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.

Yup. =)

>  > - 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.]

Terminal is presently a strange case, since it doesn't (I don't think)
retain state as it should.  For instance, on my G1G1 laptop I have a
terminal instance name "OLPC update".  I have another for hacking
around with the code.  Assuming that context (environment, command
history, scrollback buffer, etc.) was stored with these, I'd love it,
and I'd have real reason to differentiate the one from last Mon from
the one from last Tues.  I hope that such functionality will be added
to Terminal, and to most activities in the future as well.

Could you explain what you mean by your touch analogy more clearly?
I'm not sure why you would want to change the date of an entry, since
the intent of the Journal is to log the history of
interaction/creation.

>  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 is certainly a valid concern, and one that naturally wasn't first
order in the design, since the target audience is primarily kids and
teachers who have never had access to such tech before.  Full text
search is certainly something that would help, but of course indexing
an external device would take considerable time on the laptops.
Another proposal which I put forth which I encourage others to defend,
modify, or refute is this:  When scanning an external device, tag each
file with a) the name of its parent directory and b) the full path to
itself.  In this manner, I could easily type a path directly into the
search field to locate a file, or type the name of a directory, eg.
"Images", to quickly reveal everything within the directory of that
name.  Of course, there are still potential namespace collisions, but
I feel these changes could make it much easier to handle filtering of
external data.

>  << 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. >>

Agreed.  The lack of emphasis on naming is a big problem in my mind,
and I have a few ideas which could make naming something that's given
more attention, hopefully without stealing attention.  Description and
tags are a second order means of attaching meta-information to an
entry, but we hoped a) that kids naturally want to describe things and
b) we can infer enough metadata about objects (eg. size, activity,
type, creation date, participants, etc.) implicitly to make the
filters useful even without explicit tagging.

>  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.

Well, there is no "step by step" way of doing this, but the filters
are implicitly additive.  Searches are done with AND, so if you first
search for "red" and subsequently add "ball" to obtain "red ball", you
will be left with just what you expect.  Also, the individual filters
for who, what, and when are additive as you make selections to narrow
in on the desired entry.

>  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.

I do still think this is a really strong feature that we should try to
preserve if possible.  We've lost the notion of "sort by, then by,
then by" for now, but it really could completely change the utility of
the Journal for those that choose to take advantage of such a feature
if we add it later.

On a simpler note, I really do believe we have to offer metadata
search as well.  Typing in activity:write should return all instances
of the Write activity.  Typing pages:2 should return every two page
essay I wrote.  Typing in artist:beatles should return every song by
them.  Etc. Even things like haskey:my_arbitrary_category_key,
backed-up:true, etc. could be useful.  I think exposing arbitrary
metadata for search purposes will really encourage kids to use the
Journal as an organizational tool if they so desire.

- Eben