[Kde-pim] Akonadi mail migration

[Kevin Krammer]

A couple of us were discussing mail migration on IRC yesterday and that got me 
thinking.

We already have migration facilities for kresource data, so a natural path of 
action would be to do something similar for mail.
However, I think there are enough difference to make another approach more 
viable.

The KResource migration approach is based on avoiding dependencies, both as in 
code as well as in knowledge about implementation details, i.e. the migrator 
only interprets tiny portions of the resource config, it mainly delegates the 
actual migration to the resources.
This makes the migrator quite versatile but there are also drawbacks, e.g. 
inability to move data to new locations due to know actually knowing anything 
about the storage at all (could be nice to move data out of application 
specific data directories into a shared location).

The mail migrator should, IMHO, work more like an importer and therefore 
"understand" internals of the data and config it is migrating.
This should be doable since the number of possible account types is fixed and 
rather small, as is the number of possible storage formats and locations.

I imagine that the mail migrator would work alot like KMail on startup, i.e. 
processing the config and processing the mail directory tree (since it doesn't 
actually need mails at all, it would just create an "empty" folder tree).

It then has a same information available that KMail would have, e.g. it would 
know whether a folder is meant to be used as the inbox for a specific 
receiving account.
Such information could lead to a more suitable Akonadi resource setup, e.g. 
moving sub tree previously used for different receiving accounts into separate 
maildir resources.

It would also be capable to use knowledge available in its "empty" folder tree 
to annotate collections and items once it has created the respective 
resources, e.g. by understanding the data in the index files.

From the interaction point of view we have come to the conclusion that there 
might be the need for (at least optional) more user interaction.
Optional in the sense that it could come up assistant style, offering both 
"default" and "custom", where custom would allow to tailor certain aspects of 
the migration process while default would just automatically do what we deem 
best.

For example in the case of mixed tree (mbox folders and maildir folders in 
KMail's mail directory), default could just convert mbox folders into maildir, 
while custom could allow the user to decide on a per folder basis whether to 
convert or to move out of the tree into its own mbox resource.

Maybe even offer different options how to handle one-to-one POP3 account <-> 
folder associations when detected (move to separate resource vs. keep in 
tree).

Akonadi based KMail could treat this as a kind of "first startup wizard", 
others like Mailody could treat it like "import from KMail".

Does this make sense for anyone else?

Cheers,
Kevin

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring

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