[Kde-pim] Akonadi mail migration

[Kevin Krammer]

At GCDS we discusses another aspect of mail migration, namely the migration of 
disconnected IMAP (cached IMAP).
It is slighlty more complicated then migration any of the local folders or a 
normal IMAP folder since it is basically a combination of both.

Sure, the least difficult approach would be to just create and IMAP resource 
and change its foilders' cache policies, however we agree that having to 
download all message again is not something our users will be happy about.

One of our internal requirest is that the Akonadi resource (being new code), 
should not have any or minimal knowledge/dependencies on old stuff, so having 
the IMAP resource to the import is out of question.

A possible solution we came up with is the use of a special attribute for 
collections and items being imported.
This way an external process, e.g. the importer, could add things to the IMAP 
resource but the IMAP resource would understand that it is not an "add" 
operation it has to send to the server.
It would only have to set the remoteId like it would do if it had gotten the 
data from the server.

I am not thinking whether we can't use the same approach for all mail 
resources, even those which operate on the old data directly, e.g. a maildir 
resource working on a KMail maildir folder.

It would allow the migrator/importer to directly manipulate the items, e.g. 
for setting flags and attributes instead of having to wait for the resource to 
create the item and then modifing it.

The proposed procedure would change a bit to accomodate that:

On Tuesday, 2009-06-30, Kevin Krammer wrote:

> 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: create necessary Akonadi resources. Necessary probably also in
the sense to check whether some of them already exist

Phase five: add collections and items with fully setup flags and attributes. 
Mark them with a special "import" attribute so resources can treat them 
differently. Amount of payload data could depend on migration policy, e.g. all 
available payload for imports from dimap, only envelop for local resources.

(this basically combines phases four and six of the original proposal)

Phase six: optional cleanup, e.g. remove index files, dimap caches, etc.

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/20090719/b1b43fa4/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/