From kde-pim Tue Aug 19 08:03:37 2008 From: Volker Krause Date: Tue, 19 Aug 2008 08:03:37 +0000 To: kde-pim Subject: Re: [Kde-pim] Akonadi being a desktop-indepent standard Message-Id: <200808191003.40284.vkrause () kde ! org> X-MARC-Message: https://marc.info/?l=kde-pim&m=121913314220248 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============0072524587==" --===============0072524587== Content-Type: multipart/signed; boundary="nextPart2081601.YB5uHHdFgG"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit --nextPart2081601.YB5uHHdFgG Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 18 August 2008 14:45:00 Kevin Krammer wrote: > 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 > > > continue 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 > > > format 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 cla= ss > > > 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 > client 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 > case email, and Akonadi for others, e.g. contacts. > > However, ideally access to data would not depend on specific applications > 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 > 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. > > > 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/sending mail. > > The other two examples are again more about actually accessing shared dat= a. > > > 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 > on 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" whic= h, > 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 o= ne > 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 > 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. > > Till or Volker can probably give you an estimate on how much work such a > direct connection would be if one can start with the facilities of a fully > featured mail client (Akonadi's protocol being similar to IMAP in some/mo= st > aspects) It's of course possible to build such an interface on top of Akonadi. Proba= bly=20 wouldn't take too much time even, Akonadi provides this functionality more = or=20 less already. However I see two issues with this approach, issues we have=20 with our current KResource based infrastructure in KDE PIM and which were=20 crucial in the decision to build Akonadi: =2D Synchronous API. Easy to use and works nicely for 100 contacts in a loc= al=20 vcard file, but fails completely for 10k+ entries on a LDAP server with a=20 poor network connections. Therefore most methods in the Akonadi client API= =20 are asynchronous. That's much less pleasant to use of course, but in our=20 opinion the only way to deal with the amounts of data we have here. =2D Data access via applications. In KDE PIM we used that for the Kolab bac= kend=20 which uses KMail to access the server. So, every application accessing=20 contacts would launch KMail, which was extremely confusing for users.=20 Therefore we use a dedicated server for Akonadi. regards Volker --nextPart2081601.YB5uHHdFgG Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQBIqn5cf5bM1k0S0kcRArwNAJ0VopEaN2vE2pgYh2o0HsAEBMv2rgCbBIC9 Aq6QFE9b7j8bDU7U4fvCLOE= =J+/F -----END PGP SIGNATURE----- --nextPart2081601.YB5uHHdFgG-- --===============0072524587== 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/ --===============0072524587==--