From kde-pim Wed Aug 20 17:22:40 2008 From: Kevin Krammer Date: Wed, 20 Aug 2008 17:22:40 +0000 To: kde-pim Subject: Re: [Kde-pim] Akonadi being a desktop-indepent standard Message-Id: <200808201922.48601.kevin.krammer () gmx ! at> X-MARC-Message: https://marc.info/?l=kde-pim&m=121925301211498 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============0922986162==" --===============0922986162== Content-Type: multipart/signed; boundary="nextPart1477882.L3iMIZDibW"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit --nextPart1477882.L3iMIZDibW Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 20 August 2008, Holger Berndt wrote: > 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. This is why I wrote that applications such as Claws might just want to use= =20 Akonadi just for "foreign" data, in your case e.g. contacts. We understand that any kinf of migration of an application's core data will= be=20 quite some effort, we do have the same work ahead for KDE's PIM application= s. I slightly disagree that mail storage would be a core competence of a MUA=20 unless it has very tight coupling between its features and the way the data= =20 is actually stored on disk. > 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. Sounds reasonable. > 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. =2Eservice files are not good enought for this kind of scenario since they= =20 basically are very static configuration. When discussing the issue of user configurable service choice with the D-Bu= s=20 folks we ended up with an idea to use a specially priviledged service to=20 configure the activation during runtime, though nobody has started any work= =20 on implementing it. It is also a bit more complex on the application's side since they need to= =20 know when to register the respective bus name, otherwise manually launching= =20 an application which is not the preferred one will have all calls routed to= =20 itself instead of getting the preferred one autostarted. > 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. I guess as long as developers using the interface are aware of its inherent= =20 limitations that might be good enough. Though at least in the case of an Akonadi based setup using a direct=20 connection will get better results and might be preferable for applications= =20 which operate on the data as their main target, e.g. mail for MUAs. > > 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. Well, for the data access and management problem domain this is also one of= =20 the reasons for Akonadi's design, e.g. access to contact data from a MUA do= es=20 not depend on any specific implementation of an addressbook application,=20 storage location or method of access to such locations. Cheers, Kevin =2D-=20 Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring --nextPart1477882.L3iMIZDibW Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQBIrFLgnKMhG6pzZJIRAodZAJ930zW2o2bfBuSeq02LTBASszUNCQCfeQjM 9Ss7lTfLkXAYEvirTtxhWhs= =+SPC -----END PGP SIGNATURE----- --nextPart1477882.L3iMIZDibW-- --===============0922986162== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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/ --===============0922986162==--