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

[Volker Krause]

On Sunday 03 March 2013 17:13:32 Wolfgang Rohdewald wrote:
> 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 

of course, I didn't say it's *only* a cache ;) It does store meta data 
(attributes, flags, etc not supported by the backend, identifiers mappings, 
...) as well as data changes not yet written to the backend. None of these 
make it loss-less to delete the database obviously. Way to often protecting 
this data and protecting the data in the corresponding backends is mixed up.

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

IOW store the id mapping in a different place again, so it's less likely to be 
deleted?

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

IDs don't change (well, unless you delete the id mapping which is part of the 
database), so there's no way of notifying the application about that.

Also don't forget that the path string changes for entire sub trees if you 
rename a folder. And we also need identifiers for addressing data in Nepomuk, 
for every item.

Much more interesting than these workarounds is IMHO: why do you want to 
delete the database? Providing proper solutions for these use-cases seems much 
more useful to me.

regards,
Volker

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20130303/47ac4b6b/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/