[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-pim
Subject: [Kde-pim] [RFC] Akonadi design
From: Tobias Koenig <tokoe () kde ! org>
Date: 2006-05-08 14:44:28
Message-ID: 20060508144428.GA26803 () ghostdog ! localnet
[Download RAW message or body]
[Attachment #2 (multipart/signed)]
[Attachment #4 (multipart/mixed)]
Hi,
we (Cornelius, Martin Konold and me) had the chance to discuss the design
of akonadi again at the LinuxTag in Wiesbaden last week.
Martin gave some valuable input on how to make the current design even
better in respect of robustness and scalablility.
I attached a conslusion of the current design state, with a nice diagram
and some explanations.
There are still some questions left, where we should find an answer
together:
1) shall the notification manager and resource manager be part of the
storage process?
2) which protocol is spoken between libakonadi and the search provider?
3) how does the resources integrate their configuration gui into
applications (Martin?)?
4) ...
If you have questions, suggestions or objections, please speak up!
Ciao,
Tobias
--
Separate politics from religion and economy!
The Councile of the European Union is an undemocratic and illegal institution!
["abstract.txt" (text/plain)]
Akonadi Abstract
==================
Diagram
.---------------.
| storage |------------------.
`---------------' |
| .----------------------.
| extended IMAP | notification manager |
| `----------------------'
/ \ | |
/ \ | |
.-----------. / \ .-----------------. |
| resources | | | search provider | |
`-----------' | `-----------------' |
| | | |
.------------------. .--------------. |
| resource manager |-| libakonadi |-------------------'
`------------------' `--------------'
|
|
.--------------.
| applications |
`--------------'
storage
---------
A central storage which keeps all the pim data (e.g. mails, contacts and events).
The storage is a dumb data collector which knows nothing about the content of the data,
it just saves and redact them and assigns an unique id to every data object.
The protocol to access the storage is an extended version of IMAP, which allows to add, remove
and query for data objects. However the query language will a basic one and only knows
about the mimetype of the data objects but not about the format of them, so you can search
for all data objects of type text/x-vcard, but not for contacts with a given name, that's
handled one level above.
The storage is directly used by the resources, applications will access them through libakonadi
and the search provider.
resources
-----------
Resources are responsible to load data from an external source (e.g. a file, LDAP directory or
groupware server) into the storage, convert them to a common format which is used by akonadi
internally (maybe XML based) and save them back to the external source after local modifications.
They are implemented as separated processes to avoid buggy resources (yes, they really exists ;))
crashing the whole akonadi system. The communication is done over the same protocol
as the applications.
Applications can add, remove and configure resources with the resource manager (via libakonadi).
resource manager
------------------
The resource manager starts, stops and controls the resource processes and is accessable via libakonadi.
search providers
------------------
Search providers are separated processes, which does the content specific searching like
"Return all contacts which given name starts with 'A'"
or
"Return all events between 29.05.2005 and 19.07.2005"
There will be one search provider for every data object type (mostly mimetype), so one for
the addressbook, one for calendar etc.
The search providers will query all objects of the type they are responsible for from the storage,
perform the search query over these data and return a list of matching uids.
This separation between the storage and the search/business logic has the following advantages:
- bugs in the search provider won't effect the storage system and vice versa
- easy exchange of search provider (business logic) is possible
- better performance since a time consuming search won't block the storage
- better use of multicore systems when using separated processes
notification manager
----------------------
The notification manager keeps track of all changes in the storage and the resource manager and
provides these information to the search providers and libakonadi to allow change notifications
in the applications and internal triggers (e.g. updating virtual folders)
libakonadi
------------
libakonadi is the glue around all the single components and provides an easy to use, asynchronous API
to the application developer. There will be a Qt based libabkonadi for usage in Qt/KDE applications and
a plain C/Glib based libakonadi for everything else.
applications
--------------
Applications are all programs or components which want to use the Akonadi system. They'll use libakonadi
to create, remove or query data objects.
["signature.asc" (application/pgp-signature)]
___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
_______________________________________________
kde-pim mailing list
kde-pim@kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
kde-pim home page at http://pim.kde.org/
___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic