Architecture of Lobotomy
The Lobotomy Projects aims to build a complete system for general purpose computing, spreading from file management to graphic interface. It includes almost everything necessary between the kernel and the final user.
In current environments, applications provide the center of the whole model: the operating system just abstracts access to low level facilities, a set of libraries are shipped so to avoid reinvent the wheel more and more times, and each program provides to accomplish its own task and all stuffs around it. They implement management of data flow, file read and write (and interpretation of formats), graphical interface... Everything is mixed up in a single process which retain resources also when not in use by the user.
In Lobotomy, the whole system can be in some way be interpreted as a unique big application segmented into three layers which remind the Model/View/Controller pattern: the Hyppocampus storage manages raw data and unificate them in the common model, Synapse implement the complete user interface and SubConsciousDaemon populate the storage and host core functionalities required by graphic interface. They constantly communicate each other through high-level IPC.
The core of the model is the Item, which is the logic evolution for the more familiar concept of "File". Each single Lobotomy's Item can rappresents any type of information (not only images and documents, but also people or events) and are always collections of well defined and described a priori metadata, their contents also are managed exactly as any other metadata: due this abstraction, which level all data, upper layers can act on different Items trasparently, without know their nature.
The whole graphical stuffs are managed by a single application, Synapse, which provide different visualization of Items applying on them different templates (called Thoughts). Given that all Items have the same structure (groups of metadata), the template only need to explicit the layout for showing them, without know if the Item itself is an image or an audio file. We can think on Thought on Items such as XSLT on XML: given an input, always returns an output indipendently if the input is the recipe for apple pie or the lyric for a Beastie Boys song. All template can be applied to all result sets, and all result sets can be applied to each template: doing so, an infinite number of combination are available and information can be explored in new unexplored views.
Since Synapse implement only (reusable) graphic behaviours, the lower SubConsciousDaemon implements (reusable) functionalities. Here happens background jobs (fetching mail, indexing of files, automatic metadata extraction...) and requests coming from the graphic level, which from this perspective can be considered a dummy component. Synapse (accordly the running Thought) asks for SubConsciousDaemon to apply every kind of elaboration, transformation, elaboration of viewed data, and every high-level handling is abstracted throught a common interface which embrace all possible interactions. In this way, all functional logic is implemented once on the whole system and can be easily embedded in every kind of user application: the name of the function identifier is enough to apply a filter on an image, play an audio file or substitute all instance for a word in a document.
