[Kde-pim] Questions / Issues on Akonadi

[Volker Krause]

just a few small additions to Tobias' answer:

On Sunday 16 March 2008 20:33:25 Tobias Koenig wrote:
> On Sun, Mar 16, 2008 at 12:20:58PM +1100, Brad Hards wrote:
> > 1. What policies apply to akonadi dependencies? In particular, which
> > parts of akonadi are allowed to depend on which parts of KDE?
>
> The Akonadi server shouldn't depend on any KDE specific code, it's
> Qt-only currently.
> The libakonadi makes use of kdelibs and that's ok.
> The agents and resources can have any dependency they want, as they are
> separated processes.
>
> > 2. How will Akonadi manage notes / todo items? I haven't seen any more
> > detail than "kcal".
>
> Todos are handled by the kcal-resource as it was done in KDE3. For notes
> we need a new library to access them.

Also see the recent discussion about identifying KCal subtypes on this list. I 
think the current approach is using separate mimetypes for events, todos and 
journal entries and use shared pointers to KCal::Event|Todo|Journal as item 
payload.

> > 3.  Is RSS / Atom feed management in scope for Akonadi?
>
> Yes, it should be (Frank, can you say more about that topic?).
>
> > 4. How are async notifications of changes (from the server) supposed to
> > be handled? What will the application send to akonadi core, and what will
> > akonadi core send to the resource?
>
> When the resource gets a async notification from the server, it
> adds/deletes/moves the data object in the store. That will signal all
> other clients (agents or applications) that something has changed.

We might want to think about adding convenience API for server-side change 
notifications to ResourceBase, but I guess we need to see one or two 
resources supporting that first to see what common code they contain for 
that.

> > 5. [More general form of item 4] Can I have some documentation on how
> > data gets moved around, please?
>
> Hmm, that's a bit tricky to explain ;)
>
> At first the retrieveCollections() is called on the resource, so the
> resource should query its data source to build up a logical collection
> hierarchy and return it.
> Now for every collection retrieveItems() is called on the resource. The
> resource returns now all items that belong to that collection.

How much of the items is retrieved depends on the cache policy of the 
collection and the abilities of the resource at this point. You might want to 
retrieve eg. just the email header here (think online imap), additional item 
data can be retrieved later on by retrieveItem() calls.

> itemAdded()/itemChanged()/itemRemoved() is called on the resource
> whenever an item (that the resource is responsible for) has been added
> /changed/removed by an other agent/application in the store. So the
> resource shall write back that change to its data source (e.g. the
> groupware server).

regards
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20080319/fc9ae9e5/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/