|
LOBOTOMY PROJECT
|
|
HYPPOCAMPUS PROJECT
|
Mixing Types
(v0, 6.6.2007)
Abstract
One of goals for the Lobotomy Project is the infringment of restrictive data formats and the one-way-to-rappresent-data interaction we are usual. Informations formattation is a price to pay only in name of easy of treatment into applications, but for the user the information is really usefull only when "pure".
Summary:
Introduction
You have lots of file. Each of them is a different kind of information: textual, graphical, auditive... And for each kind, more types of bytes rappresentation are used from the applications: PDF, ODT and ASCII for text; JPEG, PNG and SVG for pictures; MP3, WAV and OGG for audio. And much more. Really more.
Each of them aims a particular target: one if for simple plain text, another for vector graphic, third is for text with rich formatting metadata... And each of them is consultable with a particular application, and have particular limitations: a PDF file is readable with the specific reader and cannot be grep'ed, an ASCII document is grep'able but is not graphically formatted, and so on.
But they are a structural requisition, a convention to easy management of set of bytes which have to be interpreted in different ways. User don't care about them, he only have to know he need the stored information in a file or another, so we have to gain in usability and accessibility hiding redundant details of low-level implementation and emphasing contents.
From File to Data
Staminal wants to be an extension for the Hyppocampus filesystem which traslate each type of file in an universal format traslable in everything else. When a PDF file is created, for example, the system will parse contents and create the corrispective Staminal item (which would be something in XML for texts contents) rappresenting, in separated areas, the formattation of the document and its contents; opening this item with, always as example, OpenOffice, an ODT document is assembled from the staminal metadata, so to be edited with the preferred application. Opening again the file with the PDF reader, metadata modified with OpenOffice are newly assembled and the PDF is presented modified. Opening the same file with a plain text editor, or grep'ing it, the plain contents are presented, epurated of formattation informations which, in those cases, will be redundant and uneffective.
To concretize this traslating mechanism is of course necessary a complete knowledge about formats, to explode files and rebuild them on-demand: a plugins layer will permit to add new types in the Staminal list, so to adapt the system to the requests, as it already exists for mnemonic boxes (see related documentation).
When the filesystem will be queried for files having a particular mime-type, it collect also items which are traslable in that format, and a specific API will permit applications to advance aimed requests for datatypes.
From Data to Other Data
Drag'n'drop will be a common operative way in the Lobotomy desktop environment: it permit to the user to share data between applications, and handle them skipping the selection of the item from the filesystem or the copy-and-paste method (really uncomfortable with pen-driven devices).
Until the user moves a file of a certain type from an application to another able to handle it (or a traslation of it, as seen before), the problem doesn't exists, but what happens when dropping a type which is untraslable? The answer, here, comes from relations between files, stored in the filesystem. Some of the metadata extracted from SubConsciousDaemon or explicitely edited by the user are references to other items indexed in Hyppocampus, and those relations are identified (as all other metadata) in their nature and in their meaning: when an item is not traslable into the type format required from the "drop" application, a possible response can be searched in the range of the "external" items related (directly, because present in the list of metadata assigned to the item itself, or indirectly, because the item is present in the list of metadata of another) to the one which is currently handled.
As an example, see the META_PEOPLE_INTO_PICTURE metadata listed in the available set: choosing a contact from my phonebook list an dragging to a graphic editor, there is no direct way to traslate this data type (a group of values, textual and numeric) into the required one (an image), but is possible to look for an image having the above mentioned attribute to obtain a file suitable to the destination application.
The here described concept is similar to the "plumber" daemon implemented in Plan9 operating system, with the difference that this tool provide to find the most adapt applications for a given data atom, while the tool here suggested provide to find the most adapt presentation of a data for a given working program.
