Akonadi being a desktop-indepent standard

[Holger Berndt]

Hello PIM people,

I am a supporter of the desktop independant, GTK+ based mail user agent
Claws Mail. Its (few) developers are pretty evenly split between
between being KDE, GNOME, and XFCE users.

I've thought many times that it would be great to have a
freedesktop.org standard for PIM component access and interaction.
Ideally, this would allow for all PIM components implementing this spec
to be interchangable with out loosing integration, so the user could
choose calendar, addressbook, mailer etc independantly, and still have
a fully integrated PIM suite.

This would also ease common tasks like synchronization. For example,
not every PIM suite would have to write its own OpenSync plugin, but a
single plugin implementing the spec would be enough for all PIM
solutions.

I was made aware that Akonadi may actually aim towards this goal, and
might be interested in not only supporting KDE but being desktop
independant.

Googling around I found this thread from a year ago:
http://lists.kde.org/?t=118583310600004&r=1&w=2
which goes in that direction but drifts a little off towards the
end.

What is your current view on this? Is Akonadi aiming to have no KDE
dependancies, and provide services also for non-KDE programs?

Note that many useful tasks would probably not even require a daemon,
but could be implemented client-side based on a D-Bus spec.
Synchronization would be an example, that would mostly just require a
standardized set of get/add/delete/modify interface methods for
addressbook, calendar, and notes.

Holger
_______________________________________________
KDE PIM mailing list kde-pim@...
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/

[Kevin Krammer]

Hi Holger,

On Saturday 16 August 2008, Holger Berndt wrote:
> Hello PIM people,
>
> I am a supporter of the desktop independant, GTK+ based mail user agent
> Claws Mail. Its (few) developers are pretty evenly split between
> between being KDE, GNOME, and XFCE users.

I haven't used it myself yet, but IIRC one of my friends is a big fan of its
Maemo port.

> I've thought many times that it would be great to have a
> freedesktop.org standard for PIM component access and interaction.
> Ideally, this would allow for all PIM components implementing this spec
> to be interchangable with out loosing integration, so the user could
> choose calendar, addressbook, mailer etc independantly, and still have
> a fully integrated PIM suite.

We definitely agree on this. There is enought room for any kind of
specialization or customization for different user target groups on the
application level, without need to do all the data I/O and manipulation
multiple times.

Actually both big Free Software desktops have had this goal within the
respective platform for years, so to share between them and independent
projects is almost a logical step.

> This would also ease common tasks like synchronization. For example,
> not every PIM suite would have to write its own OpenSync plugin, but a
> single plugin implementing the spec would be enough for all PIM
> solutions.

As far as I understand the OpenSync framework already allows this to some
extent, i.e. using the same device plugin independent from whether it sync to
a KDE based local store or that of another PIM project.

But of course sharing both sides would be even better, especially since the
way users expect synchronization to work has moved from explicit syncing to
happening implicitly (automatically) in the background.

> I was made aware that Akonadi may actually aim towards this goal, and
> might be interested in not only supporting KDE but being desktop
> independant.

Yes, Akonadi is intended and has been designed to be desktop independent.
The central core is basically specified by a data transport protocol and D-Bus
interfaces for out-of-band communication (notifications, etc).

There is a desktop independent implementation of the service side (Akonadi
server), currently hosted in the KDE SVN module kdesupport (software in there
cannot have any KDE dependency since it has to be built before KDE)

We are trying to get at least some project infrastructure hosted on
freedesktop.org, but the administration team there doesn't seem to have a lot
of time, i.e. we are already waiting for about four months now [1]

In the mean time we will have the option to get KDE SVN accounts for external
contributors should anybody be interested in contributing to Akonadi on any
level.

As for the client side, we concentrated on doing a KDE based client library
implementation first. It allowed us to move more quickly since we could
leverage a lot of functionality already present in KDE libraries.

Earlier this year we tried to find somebody interested in doing a GLib based
client library as a Google Summer of Code project which we would have
allocated one of KDE's slots to as a contribution to interoperability,
however unfortunately we didn't get any application for that idea, dispite a
couple of GNOME developers helping us with that.

> What is your current view on this? Is Akonadi aiming to have no KDE
> dependancies, and provide services also for non-KDE programs?

Definitely!
Even the several year old initial concept diagram emphasises that :)
http://pim.kde.org/akonadi/

The server is already implemented without any desktop specific things, even
without GUI portions of Qt, basically just using the GLib level Qt
equivalents of a GTK+ library stack.

If you and/or others are interested in implementing a GLib based and GLib
style (e.g. behaving like a GLib using developer would expect), I suggest we
try to schedule an IRC meeting so that interested developers and people with
more internal Akonadi knowhow than me (e.g. Till and Volker) have time for
analyzing requirements, etc.

Of course you are welcome on freenode channel #akonadi at all times :)

> Note that many useful tasks would probably not even require a daemon,
> but could be implemented client-side based on a D-Bus spec.
> Synchronization would be an example, that would mostly just require a
> standardized set of get/add/delete/modify interface methods for
> addressbook, calendar, and notes.

I am not so sure about that.
The daemon/service based approach avoids nasty things like file
locking/concurrent access, identifier consistency, relyable change
notifications and so on, though you probably better wait for responses of
Akonadi architects on any of your questions :)

Cheers,
Kevin

[1] https://bugs.freedesktop.org/show_bug.cgi?id=15711

--
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring


_______________________________________________
KDE PIM mailing list kde-pim@...
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/

[Holger Berndt]

Hi Kevin,

On Sa, 16.08.2008 15:08, Kevin Krammer wrote:

>> I've thought many times that it would be great to have a
>> freedesktop.org standard for PIM component access and interaction.
>> Ideally, this would allow for all PIM components implementing this spec
>> to be interchangable with out loosing integration, so the user could
>> choose calendar, addressbook, mailer etc independantly, and still have
>> a fully integrated PIM suite.
>
>We definitely agree on this. There is enought room for any kind of
>specialization or customization for different user target groups on the
>application level, without need to do all the data I/O and manipulation
>multiple times.

Re-reading project pages of Akonadi, I understand that the project is
mostly about providing a central storage and access management for PIM
data.

I am not sure many 3rd party applications would want to rely on that. I
am pretty certain, for example, that the Claws Mail dev team would not
aggree on outsourcing actual mail message storage.

>> This would also ease common tasks like synchronization. For example,
>> not every PIM suite would have to write its own OpenSync plugin, but a
>> single plugin implementing the spec would be enough for all PIM
>> solutions.
>
>As far as I understand the OpenSync framework already allows this to some
>extent, i.e. using the same device plugin independent from whether it sync to
>a KDE based local store or that of another PIM project.

Well, in OpenSync, you have plugins for hardware devices (Nokia,
Motorola, SyncML-based stuff etc) and applications (KDE PIM, Evolution,
I was working on one for Claws Mail etc.) Basically, what the
application plugin implements is listing/adding/modifying/deleting
entries in addressbooks or calendars. The Evolution plugin talks to the
Evolution Data Server for that, the KDE PIM does it the KDE way, the
Mozilla plugin talks to Thunderbird etc.

>Yes, Akonadi is intended and has been designed to be desktop independent.
>The central core is basically specified by a data transport protocol and D-Bus
>interfaces for out-of-band communication (notifications, etc).

[Akonadi's client server architectur description cut]

>> Note that many useful tasks would probably not even require a daemon,
>> but could be implemented client-side based on a D-Bus spec.
>> Synchronization would be an example, that would mostly just require a
>> standardized set of get/add/delete/modify interface methods for
>> addressbook, calendar, and notes.
>
>I am not so sure about that.
>The daemon/service based approach avoids nasty things like file
>locking/concurrent access, identifier consistency, relyable change
>notifications and so on

I see. It does seem to me, after all, that we are talking about
different things here. While Akonadi wants to concentrate data storage
and access at a central point, I was more talking about a "common
language" for otherwise independant PIM modules.

Since the goals are similar, though, maybe not all hope is lost. Let me
explain what I envision, and where Akonadi's place could be:

There could be a spec for PIM module preferences, maybe D-Bus based, in
the freedesktop.org namespace, according to which each user can define
his own choice of programs. Technically, this could be done by D-Bus
service files.

Each program supporting this spec would have to implement a
corresponding interface. Though I don't know Akonadi well, that
interface could probably be based on what Akonadi supports already
anyways. In the easiest case, the API for an addressbook could contain
something like that (D-Bus xml excerpt):

  <interface name="org.claws_mail.addressbook">
    <method name="GetContacts">
      <arg type="as" name="ret" direction="out"/>
    </method>
    <method name="AddContact">
      <arg type="s" name="contact" direction="in"/>
      <arg type="s" name="ret" direction="out"/>
    </method>
    <method name="DeleteContact">
      <arg type="s" name="uid" direction="in"/>
    </method>
    <method name="ModifyContact">
      <arg type="s" name="uid" direction="in"/>
      <arg type="s" name="contact" direction="in"/>
      <arg type="s" name="ret" direction="out"/>
    </method>
  </interface>

Data transfer should be in a well known, well defined format, such as
strings of vcards in the case of an addressbook.

Now, all PIM modules relying on Akonadi would configure the D-Bus
services for addressbook, calendar, mail, etc. to point to Akonadi.
Still, 3rd party applications could integrate seamlessly.

To come back to the synchronization example: Instead of an Evolution
plugin, a KDE PIM plugin, a Claws Mail plugin, a Thunderbird plugin
etc, only a D-Bus plugin would be necessary for all PIM components that
implement this spec.

Holger
_______________________________________________
KDE PIM mailing list kde-pim@...
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/

[Cornelius Schumacher]

On Saturday 16 August 2008 16:18:45 Holger Berndt wrote:

>
> There could be a spec for PIM module preferences, maybe D-Bus based, in
> the freedesktop.org namespace, according to which each user can define
> his own choice of programs. Technically, this could be done by D-Bus
> service files.
>
> Each program supporting this spec would have to implement a
> corresponding interface. Though I don't know Akonadi well, that
> interface could probably be based on what Akonadi supports already
> anyways. In the easiest case, the API for an addressbook could contain
> something like that (D-Bus xml excerpt):
>
>   <interface name="org.claws_mail.addressbook">
>     <method name="GetContacts">
>       <arg type="as" name="ret" direction="out"/>
>     </method>
>     <method name="AddContact">
>       <arg type="s" name="contact" direction="in"/>
>       <arg type="s" name="ret" direction="out"/>
>     </method>
>     <method name="DeleteContact">
>       <arg type="s" name="uid" direction="in"/>
>     </method>
>     <method name="ModifyContact">
>       <arg type="s" name="uid" direction="in"/>
>       <arg type="s" name="contact" direction="in"/>
>       <arg type="s" name="ret" direction="out"/>
>     </method>
>   </interface>
>
> Data transfer should be in a well known, well defined format, such as
> strings of vcards in the case of an addressbook.

Akonadi basically specifies this kind of API. It's more than a set of D-Bus
calls, because this isn't the best choice for transmitting large amounts for
data, but Akonadi provides a platform-independent API which can be used by
any PIM program.

Other applications like Claws Mail could implement their own storage with this
API or use the implementation Akonadi already has. All other programs could
then seamlessly integrate with all the other programs which use this API.

> To come back to the synchronization example: Instead of an Evolution
> plugin, a KDE PIM plugin, a Claws Mail plugin, a Thunderbird plugin
> etc, only a D-Bus plugin would be necessary for all PIM components that
> implement this spec.

Yes, that's exactly the idea of Akonadi. Implement synchronisation with the
Akonadi API and you get syncing with all apps which use this API for free.

--
Cornelius Schumacher <schumacher@...>
_______________________________________________
KDE PIM mailing list kde-pim@...
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/

[Holger Berndt]

Hi Cornelius,

On Sa, 16.08.2008 21:34, Cornelius Schumacher wrote:

>Akonadi basically specifies this kind of API. It's more than a set of D-Bus
>calls, because this isn't the best choice for transmitting large amounts for
>data, but Akonadi provides a platform-independent API which can be used by
>any PIM program.

>Other applications like Claws Mail could implement their own storage with this
>API or use the implementation Akonadi already has. All other programs could
>then seamlessly integrate with all the other programs which use this API.

How would they do that? Is that API documented somewhere?

Holger
_______________________________________________
KDE PIM mailing list kde-pim@...
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/

On Saturday 16 August 2008 15:18, Holger Berndt wrote:
> Re-reading project pages of Akonadi, I understand that the project is
> mostly about providing a central storage and access management for PIM
> data.
>
> I am not sure many 3rd party applications would want to rely on that. I
> am pretty certain, for example, that the Claws Mail dev team would not
> aggree on outsourcing actual mail message storage.

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. 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 class in the Akonadi
library provides the basis for writing a new resource to access it.

--
David Jarvie.
KAlarm author & maintainer.
http://www.astrojar.org.uk/kalarm

_______________________________________________
KDE PIM mailing list kde-pim@...
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/

[Holger Berndt]

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 class in the Akonadi
> library provides the basis for writing a new resource to access it.

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 <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

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.

Signal/slot connections are also imaginable. The mailer says: Hey,
whoever might care: I just received a mail!

All those tasks don't require a lot of data being shoveled accross
applications.

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.

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?

Holger
_______________________________________________
KDE PIM mailing list kde-pim@...
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/

[Kevin Krammer]

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 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 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 <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 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 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" which,
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
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/most
aspects)

Cheers,
Kevin
--
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring


_______________________________________________
KDE PIM mailing list kde-pim@...
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/

On Monday 18 August 2008 13:45, 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 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
> 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.

I find this statement a bit confusing. I presume what you mean by this is
that you might just use whatever default storage is accessed via Akonadi
for, in this example, contacts. But that Akonadi still doesn't actually
have its own storage - the contacts are still likely to be stored as vcard
data for example?

--
David Jarvie.
KAlarm author & maintainer.
http://www.astrojar.org.uk/kalarm

_______________________________________________
KDE PIM mailing list kde-pim@...
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/

[Kevin Krammer]

On Monday 18 August 2008, David Jarvie wrote:
> On Monday 18 August 2008 13:45, Kevin Krammer wrote:

> > 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.
>
> I find this statement a bit confusing. I presume what you mean by this is
> that you might just use whatever default storage is accessed via Akonadi
> for, in this example, contacts. But that Akonadi still doesn't actually
> have its own storage - the contacts are still likely to be stored as vcard
> data for example?

What I meant to say is that an application could still opt to access its own
data directly, e.g. in the case of Claws directly accessing its mails however
it stores them, but use Akonadi to access contacts, etc.

Basically a bit like KMail currently managing its mails but using KResource to
access the addressbook.

Of course ideally all PIM data is accessed through Akonadi, so data doesn't
have to be migrated when users switch applications, but applications are
often very closely designed around their main data type storage method and
might find it easier to just do other data types via Akonadi as a first step.

Cheers,
Kevin

--
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring


_______________________________________________
KDE PIM mailing list kde-pim@...
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/

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 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
> 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 <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 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
> 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" which,
> 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
> 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/most
> aspects)

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. 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.

- 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.

regards
Volker


_______________________________________________
KDE PIM mailing list kde-pim@...
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/

[Holger Berndt]

On Tue, 19 Aug 2008 10:03:37 +0200
Volker Krause <vkrause@...> 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@...
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/

[Holger Berndt]

On Wed, 20 Aug 2008 09:14:35 +0200
Kevin Krammer <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 <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@...
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/

On Wednesday 20 August 2008 06:08:30 pm Holger Berndt wrote:

> Volker Krause <vkrause@...> wrote:
> > .... 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