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

[Andras Mantia]

Lindsay Mathieson wrote:

> A proposal  of using Id's generated from the actual FQ folder paths has
> been suggested, which are actually unique. I don't understand
> the resistance to this. It make the akonadi db a true cache and preserve
> peoples configs in case of issue with the db.
> 

There is no resistence. The patch was posted and we discussed it (also in 
person) the problem. Both approaches have pros and cons as usual and the 
good solution is not eays.

Pros for referring to Akonadi items (e.g folders) by ids in config files:
- less, faster and more readable code: you have an id, that immeditalet 
identifies the akonadi item and thus the real item
- moving folders around doesn't affect the application's behavior. The id 
will not change
- renaming folders doesn't affect the application's behavior as the id does 
not change
- it is trule unique

Cons:
- in case the id changes for whatever reason (account removed and added back 
again, cache corrupted and recreated, synching config files between two 
different akonadi databases), they will refer to wrong items in the cache 
leading to possibly serious bugs. We indeed debate how common this use case 
is, as *in theory* aside of syncing, the rest of the problem should not 
happen.

Storing a path to a collection as an id has its share of problems.

Pros:
- *apparently* fixes the problem of syncing between the computers 
- fixes the problem of config files being out of sync when the account/db is 
recreated

Cons:
- what happens when a folder is renamed or moved? This is needs to be 
carefuly tested and thought. I *believe* that in case of filters this will 
be fine due to the way it operates (reads the path, converts to an id, and 
on exit updates the config file converting the id back to the path that will 
be the new path), but was not tested yet. For the rest of the case (identity 
configuration, folder expiration configuration) we might need a different 
approach, meaning different code in each place where we need to refer to 
folders
- the names are NOT unique. You can have two accounts with the top level 
folder called "Local folders". So a path "Local folders/Inbox" is ambigous.
This means we need an extra id for identification. My suggestion was to use 
the remoteId for the toplevel folder in plus. RemoteId is also not unique in 
general, but *should* be good enough. It will still break if you add e.g two 
maildir accounts pointing to the same folder and having the same name.
(RemoteId depends on the resource type: IMAP: the server URL, Maildir: path 
to the maildir folder; MBOX: path to the MBOX file).
- syncing will still fail between config files not under the same path, e.g 
syncing /home/andris/.kde4 and /home/andriswork/.kde4 will fail if maildir 
folders are below /home/andris and /home/andriswork
- it leads to more code and more complex solutions for keeping the 
configuration files up-to-date in case of renames or moves.

So it is not an easy decision. Another solution is what Volker said: 
export/import feature. If that is scriptable (e.g you can call in a script 
to export the config files and then import it), it solves the syncing 
problem, but not the others.

I still try to make the use path instead of id working for filters. Well, 
actually works, but with the listed limitations and that cannot go into 
master as it is. You can test (the patches was posted), but with a big 
disclaimer and make sure you keep your config file for filters backed up, as 
the actual path stored in the file might change as I improve the code.

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