[Kde-pim] Marketing blocker collection, DEADLINE: 2013-03-10

[Wolfgang Rohdewald]

Am Sonntag, 3. März 2013, 16:22:07 schrieb Volker Krause:
> It's a wrong conclusion from the statement that Akonadi is a cache for data 
> stored in its respective backends.

but Akonadi is more than a cache - it generates and exposes unique
folder ids. Clients like kmail expect those to be persistent. A true cache
should never generate persistent data. In a true cache, the cache key
should be the same used to access the store backend. Of course with
a prefix defining the backend when several backends might generate
the same keys.

So if Akonadi was a true cache, it would only pass on backend information.

If the akonadi cache would additionally maintain the relation foldername-collection
id somewhere else, like in .kde/share/config/akonadi_maildir_resource_0rc,
deleting the akonadi data base could be "safer", because akonadi cache
could first lookup a foldername (whole path of course) in that config file
and only issue a new unique ID if not found.

Of course it would have to sync database and config file.
Could there be situations where akonadi would need to tell kmail that
a collection id has changed?

-- 
Wolfgang
_______________________________________________
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/