Akonadi Questions
I've recently been looking at Akonadi again, and trying to understand its design goals, implementation, and so on. The documentation on the web site is pretty thin on the ground, so I have a few questions which I'd love any friendly Akonadi developers to reply to (note that I'm biased towards the address book side for now).
- IPC. Akonadi uses IMAP for most operations, with DBus used for notifications and other "control" messages apparently. As IMAP supports notifications fine, why not drop DBus entirely? To use Akonadi there has to be an IMAP connection, correct?
- Data format. How is something concrete, like a contact, represented? In what format would it be stored in the "local addressbook", and in what format is it transferred over IMAP?
- Dependencies. For a GNOME component C++ I can just about handle, Qt is pushing it, and libkde is out. What are the real dependencies of Akonadi, and can they be reduced?
- Examples. Can anyone provide example code of basic operations against the addressbook, such as searches, handling live views, adding and removing contacts?
Thanks!
NP: Artists Like: Skalpel, Last.fm
Posted by Boudewijn Rempt at Wed Jan 30 11:34:03 2008:
Have tried contacting Till Adam directly? (adam at kde dot org). He'll be able to answer your questions authoritatively.
Posted by Ross at Wed Jan 30 11:37:58 2008:
Posted by Ali Sabil at Wed Jan 30 11:43:40 2008:
Hello,
Have you looked at: https://launchpad.net/people-project ?
It is still young and not very usable, but it aims at providing a desktop neutral solution. However it only targets Contacts and social networking possibly.
Posted by Torsten Rahn at Wed Jan 30 12:05:10 2008:
Have you looked at: https://launchpad.net/people-project ?
It is still young and not very usable, but it aims at providing a desktop neutral solution. However it only targets Contacts and social networking possibly.
Ali Sabil:
Akonadi is desktop neutral already:
http://pim.kde.org/development/meetings/osnabrueck4/overview.php
Mission Statement:
We intend to design an extensible cross-desktop storage service for PIM data and meta data providing concurrent read, write, and query access. It will provide unique desktop wide object identification and retrieval.
Posted by Andre at Wed Jan 30 12:05:26 2008:
Akonadi is desktop neutral already:
http://pim.kde.org/development/meetings/osnabrueck4/overview.php
Mission Statement:
We intend to design an extensible cross-desktop storage service for PIM data and meta data providing concurrent read, write, and query access. It will provide unique desktop wide object identification and retrieval.
As far as I know only libakonadi (the client side) is going to depend on Qt. The dependency to kdepimlib is temporary as it is not yet finished. The server components will have no dependency to KDE or Qt. IIRC it is even designed with EDS as archetype in mind. At least this is what I remember from reading.
Posted by Kevin Krammer at Wed Jan 30 14:55:53 2008:
I am not deep enought into Akonadi yet to answer (1) or (2)
ad (3): for the Akonadi server the intention is to only depend on Qt without the UI portions. The implementation currently depends on kdelibs as well for the Unix socket handling, however I will remove this with QLocalSocket as soon as qt-copy in KDE's SVN repository is updated to Qt4.4
Our (KDE's) implementation of client library is intendend for KDE application and such has all kind of KDE niceties and AFAIK the idea is that this side of the protocol depends quite on the design philosophies of the application software stack (e.g. event loop vs. threading) so wrapping doesn't make that much sense.
ad (4): In december I started to play with an implementation of your eds-embedded D-Bus interfaces on top of Akonadi to see how well the concepts would match. If you're interested, I'll try to clean it up a bit and make it available somewhere.
Posted by Sven at Sun Feb 3 16:24:26 2008:
ad (3): for the Akonadi server the intention is to only depend on Qt without the UI portions. The implementation currently depends on kdelibs as well for the Unix socket handling, however I will remove this with QLocalSocket as soon as qt-copy in KDE's SVN repository is updated to Qt4.4
Our (KDE's) implementation of client library is intendend for KDE application and such has all kind of KDE niceties and AFAIK the idea is that this side of the protocol depends quite on the design philosophies of the application software stack (e.g. event loop vs. threading) so wrapping doesn't make that much sense.
ad (4): In december I started to play with an implementation of your eds-embedded D-Bus interfaces on top of Akonadi to see how well the concepts would match. If you're interested, I'll try to clean it up a bit and make it available somewhere.
Question 1 is very interesting. Would be great if someone from the Akonadi-Team gives information for that design decision.
Posted by Ross at Sun Feb 3 16:33:50 2008:
Till Adam said: "Yep, there has to be a connection, but we think that the notifications and other aspects of the control data should be of interest to applications on the desktop which do not care about the actual bulk data at all. We want those to be able to interface with Akonadi without any intermediate library, ideally, if they prefer."
I'm not convinced myself, the notifications should be able to be sent over IMAP.
Posted by Anonymous Peon at Thu Mar 20 16:34:56 2008:
I'm not convinced myself, the notifications should be able to be sent over IMAP.
Just had a glance at Akonadi and it seems to make sense; if it's "yet another Evolution Data Server replacement" (and then some), it speaks IMAP and bridges to any "desktop" apps that should speak DBUS but conceptually shouldn't have to know the particulars of POP, IMAP, or potentially Jabber, Internet Mail 2000, or other protocols (the ubiquitous biff applets?).
(Also, a big 'thank you' to anyone working on contact managers and task managers; existing projects are either very limited, including Evolution, or designed for megacorps with staff devoted to LDAP management. Hopefully someone can split the difference; 'infinite number of phone #s and addresses per contact' is a big deal for me, as is a hierarchial view with priority propagation for tasks, so I can view per-client and see which physical files need to be where (law office scenario).)
(Also, a big 'thank you' to anyone working on contact managers and task managers; existing projects are either very limited, including Evolution, or designed for megacorps with staff devoted to LDAP management. Hopefully someone can split the difference; 'infinite number of phone #s and addresses per contact' is a big deal for me, as is a hierarchial view with priority propagation for tasks, so I can view per-client and see which physical files need to be where (law office scenario).)
