|
LOBOTOMY PROJECT
|
|
BRAINTOP PROJECT
|
Split to Integrate
(v0.1, 26.8.2007)
Abstract
In this paper is discussed the next architecture of the Lobotomy desktop environment, described as a single MVC system: the approch to the applications, the basic concepts for the framework, and the integration between existing and future components.
Summary:
Introduction
In modern (and older) Desktop Environments, the environment itself is just a shell into which we found a series of self-contained applications: the mail client provide to fetch and present mails, same for the RSS aggregator, the multimedia player permits to choose a file and execute it, and so on. More the environment is advanced, more the underlying framework is rich of features and more is possible the integration between different programs, but the architecture is always the same.
A lot of different applications run on the system, needing RAM memory and a place in the kernel's process table and scheduler queue, and holding always the same problems: after years of mail clients, today to start a new mail client project I have to choose a library to interface to the mail server (or implement the protocol myself), define and build the user interface, handle the user's configurations, and debug everything. (Don't try this at home! World don't need another mail client, this is just an example!).
We can do better. We can start thinking another kind of "integration". A type of "integration" where features are independent from the single application, but offered as a service for the whole system.
We can build the desktop environment as a Model-View-Controller system (or something which looks as).
The Model
Almost all applications handle data, and to start integrate applications we need to integrate data.
In Lobotomy, the "model" component is Hyppocampus. The relational filesystem handle in the same way files, mails, contacts, RSS feeds, dates, notes, applications, abstract informations. Everything. All elements are described in a universal format: the contents and the assigned metadata, mapped into a know schema. The abstraction layer implemented in LibHyppo permits to access metadata (and, in the next future with the definition of the Staminal API, contents. See "Mixing Types" document for details) in a unique, well know and documented way.
The Controller
Having a storage for data, we need to feed and manage it, as to provide basic services which can be used both from the model than (especially) from the view.
The most rappresentative component for the "controller" layer in the current Lobotomy landscape is SubConsciousDaemon, which silently provide to automatically extract metadata from elements placed in Hyppocampus, but a lot other daemons are planned to this set: here will be the mail fetcher, as the abstraction for the P2P network, or the multimedia player, all referencing the "model" to get and put informations.
In general, here is the batch soul of the system, and are concretized all low (and not-so-low) level service, independently from the graphical rappresentation of the collected/elaborated data (handled in the "view" layer) and accessible through a inter-process communication API which can be the well know DBus.
The View
Finally, with a model for the data and a set of fundamental services to use, we have to present something to the user.
The presentation of data have to be the only target for the so called "user applications", which, in the perspective here described, are reduced to mere formattation of items on the screen.
The "view" layer will be implemented as a sort of XSLT interpreter included into Synapse, and applications will be distributed as XSLT files describing the elements of the user interface (mapped through a described schema, eventually inspired by XUL, and implemented in Kiazma but not only, see below), the position and the dimension of those elements, and the indications about visualization of metadata for the files involved in the result set to which the trasformation is applied.
The classic example is the mail client: having a result set from the model (which can be the list of all mails received, but also the list filtered by sender, or by keyword, or ordered by size of the attachment...), in the XSLT program I can say to show a list of all items, with the value for metadata "author" here and the "creation date" there, the "subject" up, the "contents" down, the list of "group"s at left, and a pair of buttons invoking a form for the composition of new messages and the reply, action which will be performed by daemons in "controller" layer.
The Everything Else
Splitting the whole system in the above described three layers we obtain a more debuggable, long-term stable, efficient, portable, flexible and fast developed system. The services are developed in a separated environment than the user interface, the user interface is boxed into the Synapse's intepreter and allocated only when needed (of course, the "controller" for mails acts also when the graphical application to handle mails is closed), adding a new service it is available for all applications trasparently, and XSLT trasformations on data can be used for more targets (the mail client in the previous example can be used also with a result set composed by RSS feeds).
Having data separated from presentation, and with applications abstracted via XSLT, the "view" layer can be canalized in different ways than the user's screen: I can transform it in XHTML and present in a browser (web desktop?), or refer different "model"s remotely distributed (handling the playlist of the audio player from a room to another, or from the mobile device in the pocket).
Links
