From kde-pim Mon Aug 18 12:45:00 2008 From: Kevin Krammer Date: Mon, 18 Aug 2008 12:45:00 +0000 To: kde-pim Subject: Re: [Kde-pim] Akonadi being a desktop-indepent standard Message-Id: <200808181445.09482.kevin.krammer () gmx ! at> X-MARC-Message: https://marc.info/?l=kde-pim&m=121906361606192 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============0886793838==" --===============0886793838== Content-Type: multipart/signed; boundary="nextPart1324763.vYAjr3jeE0"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit --nextPart1324763.vYAjr3jeE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 18 August 2008, Holger Berndt wrote: > David Jarvie schrieb: > > Akonadi provides data access and caching, not data storage. So there is > > no question of outsourcing actual mail message storage - you can contin= ue > > to store data in the format you currently use. > > Thanks for explaining that to me. > > > To access a data store, > > Akonadi uses a 'resource' which knows about the particular storage form= at > > and how to access it. If you want to store your email data in mbox > > format, for example, an Akonadi mbox resource will be required. If no > > resource currently exists for a storage type, the ResourceBase class in > > the Akonadi library provides the basis for writing a new resource to > > access it. While Akonadi server is not a storage itself as David explained, from a cli= ent=20 application's point of view it acts as a storage. An application could still use its own storage for some data, e.g. in your= =20 case email, and Akonadi for others, e.g. contacts. However, ideally access to data would not depend on specific applications=20 since it results in export/import task when changing between them. > Unfortunately, that doesn't help in the problem domain that I had in mind. > > As I said before, my interest is more for independant, stand-alone PIM > components to speak a common language in order to interact during common > PIM tasks. Let me give a few more examples: > > 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. Akonadi is about solving domain one, centralized access to shared data. Domain two could probably be solved by using a "preferred application=20 launcher" approach, e.g. like launching the preferred application for a=20 certain URI and MIME type, though this would need some extenting to allow t= he=20 caller to be notified once the operatation is completed. > Similarly, the addressbook could ask the MUA to open up a new message to > contact xy. Or the calendar could ask the MUA to send out invitations to > a newly created event. The addressbook could ask the calendar to add > birthday entries for all contacts. > > A sync engine could ask the notes program, the calendar, the mailer, and > the addressbook to get/add/delete/modify entries. Etc. pp. Hmm, right, there should probably be an interface/spec for composing/sendin= g=20 mail. The other two examples are again more about actually accessing shared data. > Signal/slot connections are also imaginable. The mailer says: Hey, > whoever might care: I just received a mail! True, in an Akonadi setup this already happens, like for any other change o= n=20 data items. > 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,= =20 assuming you want the actual contact contents, could be quite some data. > Having a central daemon for data access isn't needed there, and is IMO > even counter-productive. What would be needed for that was really just > an interface definition which interested applications could implement. Definitely for problem domain two, though I am not so sure about domain one= =20 due to potentially requiring quite some data transferring. > Therefore, I understand that this is not the core problem domain that > Akonadi wants to address. If, on the other hand, Akonadi would also > implement such an interface, all applications relying on Akonadi would > be accessible from outside. Are you guys interested in that kind of > interoperability? I think that KDE PIM in general would certainly be interested in the proble= m=20 domain two type of interaction and if others are interested in home-user=20 level data size or D-Bus base iterator style access we could certainly=20 implement this as a special form of Akonadi client, though it might be more= =20 efficient to access the data directly using a direct connection to the=20 Akonadi server. Till or Volker can probably give you an estimate on how much work such a=20 direct connection would be if one can start with the facilities of a fully= =20 featured mail client (Akonadi's protocol being similar to IMAP in some/most= =20 aspects) Cheers, Kevin =2D-=20 Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring --nextPart1324763.vYAjr3jeE0 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) iD8DBQBIqW7MnKMhG6pzZJIRAmbXAJ9BmlMxCH+mxUMfmGKWJ1NBXG9MuQCfZNgq UU4s2gv5R/+eiV5X5NGUtPo= =erkf -----END PGP SIGNATURE----- --nextPart1324763.vYAjr3jeE0-- --===============0886793838== 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/ --===============0886793838==--