Akonadi

[Jens Müller-10]

Hi all,

As this seems to be a hot topic, here are some of my thoughts:

- For a general exporter we need a api how to add, update & list items and
collections, we can define our own api or use a existing one like KIO or
Akonadi. With that api a host application can list collections inside their
own and do the editing. That api should devide view (widgets, etc) from data
so that each host application could show collections in their own prefered way
(lists, trees, comboboxes), there should only be some 'hooks' to dialogs
asking for new album properties etc.

- As there are existing apis we should consider them first instead reinventing
the wheel.

- For KIO I also implemented a slave as a tryout listening albums and items.
Keywords etc can be stored in own defined attributes inside the uds entries.
But I did not found it usable as the item-idents change on the gallery api
side. A items is identified by filepath on your local machine and by a id on the
gallery api (flickr, picasaweb, ...) To sync we need to store it back to the
local item, which I found problematic with KIO.

- For Akonadi we get a huge dependency (which I do not like) on board, but we
have mechanism for caching and perhaps for synchronising. Thats why I tried
this one out next.

- I do not know what's the opinion of each on the Akonadi approach, but there
seems to be differencies.

- I build these tryouts only to know what about talking and to see where are
the advantages and where are the disadvantages and if they can be solved.
- So building a tryout do not mean that this should be the preferend solution
at the end.

If you have also do some research please let me hear on the results. I would
also be encouraged to hear each's viewpoint on this topic.

Best, Jens

> HI Jens
>
> I'm not convinced yet to use Akonady to export something somewhere.
>
> It sound a big piece of puzzle to do this job. But it just my viewpoint.
>
> Personnaly, working to factoring all export/import tools
> implementation sound better.
>
>Best
>
> Gilles Caulier

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

> - For Akonadi we get a huge dependency (which I do not like) on board, but
> we have mechanism for caching and perhaps for synchronising. Thats why I
> tried this one out next.
>
> - I do not know what's the opinion of each on the Akonadi approach, but
> there seems to be differencies.

The idea of using Akonadi originates from Colin Guthrie, but he is seemingly
disappeared from kipi plugin development.
During the coding sprint in November Tom Albers gave a talk about Akonadi, the
consensus seemed to be to develop into that direction. Tom also started some
coding, but I dont know in details. Luka Renko was most directly involved in
this discussion. There were a few blog entries in the following days, IIRC
also from toma.
I consider myself primarily a digikam and not a kipi plugin developer so I
will not be involved too closely in this, but I suggest communication with Tom
Albers and Luka Renko at this point.

Marcel
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel