From kde-pim Wed Aug 20 08:08:54 2008 From: Holger Berndt Date: Wed, 20 Aug 2008 08:08:54 +0000 To: kde-pim Subject: Re: [Kde-pim] Akonadi being a desktop-indepent standard Message-Id: <20080820100854.3bace798 () wodan> X-MARC-Message: https://marc.info/?l=kde-pim&m=121921995208749 On Wed, 20 Aug 2008 09:14:35 +0200 Kevin Krammer wrote: > However, ideally access to data would not depend on specific > applications since it results in export/import task when changing > between them. I can see the usefulness of this approach, however, that's not really an option for Claws Mail. While being great for newly created clients, I doubt many older ones (except KMail, of course) will want to depend on Akonadi for data storage soon. That's too much of a core competence. I see potential for cooperation elsewhere. > > What a MUA could request: > > - dear addressbook, whoever you might be, please add the following > > contact: John Doe > > - dear addressbook, please give me a list of all contacts > > - dear addressbook, please open up contact xy for editing. Or just > > show me your main window. > > - dear calendar, whoever you might be, I just received a meeting > > invitation via email. Please insert that event into my calendar > > IMHO this mixes two problem domains. > > Domain one is about accessing data, examples 1, 2 and 4 > Domain two is about delegating data manipulation, example 3 above. These surely are two different layers, yes. > Akonadi is about solving domain one, centralized access to shared > data. Understood. This is not really a problem though. One would just have to take care to split data manipulation services from UI services, so maybe say have a org.freedesktop.pim.addressbook.datastorage and a org.freedesktop.pim.addressbook.ui service. In the case of KDE, the former could be implemented by Akonadi, and the latter by Kontact. In the case of GNOME, the former by EDS, the later by Evolution. Claws Mail would handle both. > Domain two could probably be solved by using a "preferred application > launcher" approach, e.g. like launching the preferred application for > a certain URI and MIME type, though this would need some extenting to > allow the > caller to be notified once the operatation is completed. I woudln't base it on an URI or MIME type, but on those services defined above. The user would select which application/daemon was to provide the org.freedesktop.pim.addressbook.datastorage service, which to provide the org.freedesktop.pim.calendar.datastorage service etc. D-Bus already has the infrastructure for that using .service files. > > All those tasks don't require a lot of data being shoveled accross > > applications. > > Not entirely true. One of your examples above is "list all contacts" > which, assuming you want the actual contact contents, could be quite > some data. That is true for e.g. company-wide addressbooks, or shared calendars. That's not really a show-stopper, though. Possible solutions would be to put limits in the API (give me the next 100 contacts, and tell me whether we're done already), or access local storage only. Frankly, when I want to sync my cell phone, I am not synching against the 300.000 entries company LDAP server. > > Are you guys interested > > in that kind of interoperability? > > I think that KDE PIM in general would certainly be interested in the > problem domain two type of interaction and if others are interested in > home-user level data size or D-Bus base iterator style access we > could certainly implement this as a special form of Akonadi client, > though it might be more efficient to access the data directly using a > direct connection to the Akonadi server. That's good news. I am not saying KMail has to talk to Akonadi using such a spec. Specialized access can always be more efficient than a general spec. The whole point of me starting this thread, however, is to have a common language that does explicitely NOT rely on the application itself. 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/