[Kde-pim] Akonadi mail migration

[Ingo Klöcker]

On Tuesday 30 June 2009, Kevin Krammer wrote:
> On Tuesday, 2009-06-30, Jon Armond wrote:
> > 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.
>
> Right.
> I think the key is to transform the tree, a bit like applying a XSLT
> transformation but with several processing phases and potentially
> asynchronous.
>
> Phase one: build current trees (imap and dimap should at least be
> represented by a top level node) from on-disk structure and config.
>
> Phase two: evaluate current situation, e.g. whether it is a mixed
> tree, whether there are folders designated as special folders, etc.
>
> Phase three: restructure trees (based on policy or user decisions) in
> memory, perhaps keeping a list of actions for each node.
> I imagine this phase to be undo/redo capable, i.e. allowing and
> advanced user to check "what-if" scenarios.
>
> Phase four: copy/move/convert data, e.g. create maildir from mbox,
> move subdirectory maildir out of tree
>
> Phase five: create necessary Akonadi resources. Necessary probably
> also in the sense to check whether some of them already exist
>
> Phase six: synchronize the collection trees and apply collection
> settings/attributes. Map collection identifiers from/to folder
> identifiers for updating filters and application specific folder
> configs.
> Fetch items of mbox resources and apply flags/attributes from index
> files.
>
> Phase seven: optional cleanup, e.g. remove index files, dimap caches,
> etc.

In any case we have to make sure that no mail is lost. In particular, 
the conversion from mbox to maildir could result in the loss of mail if 
the index of the mbox file is corrupt. Therefore I suggest to keep the 
old mbox file around (maybe in a special "old mail" resource containing 
backups of all mbox folders that were converted to maildir).


Regards,
Ingo
-------------- 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/e442e6b4/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/