On Wed, May 7, 2008 at 11:04 AM, Mikus Grinbergs <[EMAIL PROTECTED]> 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 _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel