On Tue, 19 Aug 2008 10:03:37 +0200 Volker Krause wrote: > It's of course possible to build such an interface on top of Akonadi. > Probably wouldn't take too much time even, Akonadi provides this > functionality more or less already. That's good news. > However I see two issues with > this approach, issues we have with our current KResource based > infrastructure in KDE PIM and which were crucial in the decision to > build Akonadi: > > - Synchronous API. Easy to use and works nicely for 100 contacts in a > local vcard file, but fails completely for 10k+ entries on a LDAP > server with a poor network connections. Therefore most methods in the > Akonadi client API are asynchronous. That's much less pleasant to use > of course, but in our opinion the only way to deal with the amounts > of data we have here. In my oppinion, that's a specification detail. The current discussion is mostly to find out whether or not the KDE PIM team would be interested in this level of interoperability. If the spec was based on D-Bus, there wouldn't be a problem anyways, because D-Bus is capable of asynchronous function calling. A spec could even specify both, maybe the synchronous version with timeouts or limited number of entries in case of a query. > - Data access via applications. In KDE PIM we used that for the Kolab > backend which uses KMail to access the server. So, every application > accessing contacts would launch KMail, which was extremely confusing > for users. Therefore we use a dedicated server for Akonadi. I don't really get this point. If the user specifies that he wants his contacts to be handled by Akonadi, then Akonadi would deal with it. If it happens to need KMail for that (I thought Akonadi didn't have KDE deps?) -- well, too bad, but IMO no reason to drop the general possibilities of other programs querying Akonadi for data. Holger _______________________________________________ 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/