[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-pim
Subject:    Re: [Kde-pim] Akonadi being a desktop-indepent standard
From:       Brad Hards <bradh () frogmouth ! net>
Date:       2008-08-20 8:36:01
Message-ID: 200808201836.01659.bradh () frogmouth ! net
[Download RAW message or body]

On Wednesday 20 August 2008 06:08:30 pm Holger Berndt wrote:
> Volker Krause <vkrause@kde.org> 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 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.
I think you've missed Volker's point. Read the introduction again: he is 
describing the problems with KResource framework, and explaining why Akonadi 
is different.

I think the message to take away from this is:
1. Do not build anything that relies on synchronous operations.
2. Do not have anything access your data indirectly (i.e. through an 
application).

Brad

_______________________________________________
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/
[prev in list] [next in list] [prev in thread] [next in thread]