Hello, As pointed out elsewhere, the NLS system had a data storing and sharing mechanism called "Journal". It allowed full-text search, versioning, hyperlinking/annotations and sharing among users.
http://www.bootstrap.org/augdocs/augment-33076.htm The sharing and searching let people do interesting things; like when somebody stored a document that includes "To: DCE" in the document somewhere, and if DCE searches for "To: DCE", the resulting list automatically became his message inbox, for example. Anyway, that is a bit of historical background (so anybody who thinks the OLPC's journal is a new idea, I have a bit of issue^^:) And there are some requirements/desire for the new system: + Recent discussion goes that some people use full text searching more, and tagging less. And, my observation is that kids are not going to tag documents, if it has to be done in a separated window. "Out of Sight, Out of Mind" is the proverb. + There is some desire to support legacy applications seemlessly. + And also, there is a need for running Sugar on the other operating systems. These things suggests that the whole concept of "metadata" may not be a good one. So, here is another simple Journal-like data organization idea. - In the Activity/Application UI, the place for tags, document title, etc. should be readily visible. For example, in a word processor, an "empty" document contains something like: Creator: yoshiki Title: No Name from the beginning. These "fields" are just text. The user may "fill" them at any point, and when the document is saved, these lines are also saved as a part of the same data. (By default. More to come later.) When I was a school kid, that was how I and all other students wrote essays. It is just a blank paper with grids and, I just wrote the name and title in the same way as the main body of the essay. - For a JPEG picture created by Record, the data can be stored in a comment in EXIF. - For an application like Etoys, the data file is actually a zip containing a few files. The "metadata" can be stored as another fixed named file in the zip. The word processor example can do something like this, too. - Optionally, the programmer of an activity writes a little program that knows how to extract the data. (let us call it a "metadata extractor".) - An activity simply stores the data file into a file system location. So, unmodified X application can save data. - The new "Journal" system calls the metadata accessor to extract the data. Journal can certainly cache it. - Let us say for every week, the Journal can create a new directory for the activity. The data stored in the previous week or time period stays in a directory. So that let you access the old data in a time-indexed manner. So, the advantage of this approach is: - An unmodified application can save and load data from file system. - Any platform can support this. We don't have to rely on the DBus, but also it is not incompatible with the already Sugarized acitivities that can save data via DBus; the backend of Journal stores the file into the proper location. - The application programmer can write a small program and the Journal can extract the metadata for better views. But it is optional; even without the extractor, the system runs fine. - The time-based access can be made fast. A downside is: - It wouldn't be easy to get some kind of metadata like "who you worked with". But there can be an API to query it from an activity and the activity can store it in the data. Alternatively, we can still recommend people to do DBus-based access to Journal when possible, and Journal could add it for the activity. Just a thought. I shared this now and then with some people, but it seems to be a good time to brain dump^^; -- Yoshiki _______________________________________________ Sugar mailing list [email protected] http://lists.laptop.org/listinfo/sugar
