[Kde-pim] New feature: Hypervisor

[Alessandro Accardo]

Hey guys,
I write this email because of a new feature for akonadi I'm trying to develop 
according to dvratil on IRC. This paper below is a sort of analysis and 
somehow a technical documentation, but is incomplete.
I hope you guys can complete this and develop together this interesting piece 
of software.

Bye,
kLeZ-hAcK.


Akonadi Hypervisor

 1  Introduction
Akonadi Hypervisor will be a new feature of Akonadi server which is needed for 
the concept of bringing up only the requested or mandatory resources when 
akonadi is started from a client.
This mechanism introduces some new concepts for akonadi that will surely 
improve its performances as well as consume less resources.

 2  Akonadi Resources and Agents
An akonadi resource that wants to be hypervisor-enabled, will have to:
* declare its managed MIME types (as an array of plain strings, better if 
matching with constants or a mime types list file)
* declare its managed types of items, if any
* register as a client of its needed resources/agents, if any
* register the needed sync events, introducing the concept of weak and strong 
sync

 2.1  Registering as a client of resources and agents
What it means to be “registered as a client” is, telling (via Dbus) to the 
hypervisor which resources and agents a client needs to be fully functional. A 
client can be whoever can access Dbus and send a message standardized as a 
client registration for the akonadi hypervisor.

 2.2  Extending the synchronization concept
Synchronization for resources is a plain routine where a resource queries in a 
given way its data provider, aggregating and structuring this results in order 
to pass them to the akonadi backend.
We want to extend this concept introducing the meaning of Weak Synchronization 
and Strong Synchronization.

 2.2.1  Weak Synchronization
A weak sync is a type of operation that can be executed at a given time, if 
the resource is alive, without other concepts. It is mainly what happens now, 
when akonadi is brought up after the sync period passed.

 2.2.2  Strong Synchronization
This is the brand new concept, that is well explained by an example. When a 
user chooses the Strong Sync a resource should schedule itself in the 
hypervisor schedule process (via Dbus). This means that, if the resource is 
down and the schedule time arrives, the hypervisor brings up the resource 
giving her the time to synchronize and then, when finished, if there are no 
clients who want to use it, simply shuts down this process, gaining memory.

 3  The Akonadi Hypervisor
The Akonadi Hypervisor is a process, started by the akonadi_control, that acts 
as the core of that functionality. A core process is needed because of 
cleanness of the akonadi_control code, and because of the various actions 
performed by the hypervisor itself that, if performed by akonadi_control 
instead, can bring to a big unnecessary complexity in the code and possibly 
even to a lack of performance. Treating the hypervisor as a separate process 
brings up even the possibility to shut down the new function if not needed or 
if not working, bringing akonadi_control to remain a robust piece of software, 
leaving it almost untouched.

This process will do the following:
* listen to Dbus for incoming messages of registration from clients
* keep a timer thread with the Strong Synchronizations requested
* bring up or shut down those resources and agents needed or not by the 
clients

 3.1  Registering clients
>From the hypervisor point of view, registering clients means write up the 
information of that clients to its configuration repository (either a 
database, a rc or something else).
The needed (mandatory) information that we must be sure to write up to the 
configuration are:
Client name: a name communicated by the client itself
MIME Types: requested MIME types that the client needs to work properly
Types of items: requested types of items that the client needs to work 
properly

 3.2  Capability
The capability is in fact a property of the clients, but is treated here 
because it has to be communicated by the clients to the hypervisor, via Dbus.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20130930/20546b7c/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/