[Kde-pim] Akonadi mail migration

Jon Armond jon.armond at gmail.com
Tue Jun 30 10:29:15 BST 2009


Kevin Krammer wrote:
> 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.

In the current incarnation the kmail migrator simply goes through the list 
of accounts creating corresponding akonadi resources.

As Kevin notes, folders are more complex because some are depended on by 
some accounts and can be made of mixed maildir/mbox trees.

So I'm going to write something that constructs a skeletal representation of 
the folder tree, migrates that to akonadi LocalFolders (asking questions as 
necessary), fixing up the config file (so accounts and filters etc still 
point at the right folders). Then migrating the accounts is simple.

Jon

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



More information about the kde-pim mailing list