[Kde-pim] Akonadi mail migration

[Thomas McGuire]

Hi,

On Monday 29 June 2009 19:29:24 Kevin Krammer wrote:
> 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?

I like the ideas here.
About having one maildir resource per POP3 account, with associated trash, 
inbox etc folders: That is an old wish (see bug 97205).
I didn't think about that when talking to Constantin about the LocalFolders 
class though, I think support for that would require modifications to 
LocalFolders.
(For those who don't know: LocalFolders is a helper class in akonadi/kmime 
that returns the inbox, drafts, trash etc folders for you, and creates them if 
they are not there yet).

For the migration: The folder settings like icons should also be migrated if 
possible. In fact, we need to have the options of the old folder dialog also 
in the new KMail. I don't think all of them can be moved to the Akonadi side, 
like the already existing icon setting, as some of the options are KMail 
specific. So we would need to wait until the folder tree and folder dialog is 
ported to be able to do the full migration.

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