[Kde-pim] Mail migration/import

[Kevin Krammer]

Hi all!

The recent commit by Volker reminded me that I wanted to write about migration 
and importing again.

I have been thinking about methods to migrate and import mail (could be 
extended to other data types of course) in a generic way, i.e. without needing 
a lot of support by the target resources.

The idea is based on the assumption that the migrator or importer has the best 
knowledge about the source situation, e.g. localation and format of 
configuration, data and metadata. Therefore it has to be the one driving the 
process.

In short I imagine it to work like this:

- migrator/importer creates target resource(s), configures them

- synchronizes them with minimum level of required information (e.g. no 
payload if the remote id can be mapped, just headers if this is enough, etc).

- add items that are not yet present, remove items no longer present, adjust 
other items if necessary, e.g. add attributes/flags.

In order for the target resource to distinguish between adding things to the 
cache and actually adding things to an item, it sets a special attribute 
containing three sets of identifiers: flags, attributes and payload parts 
which are part of the item modification and are not yet available to the 
resource.

Scenario 1: migrating KMail maildir to Akonadi maildir
migrator modifies items by adding flags and attributes it gets from the 
respective index files. No need for any payload parts

Scenario 2: migrating KMail mbox to Akonadi mbox
basically identical to Scenario 1

Scenario 3: migrating KMail mbox to Akonadi maildir
resource only reports empty top level collection, migrator adds all items

Scenario 4: migrating KMail dimap to AKonadi imap
migrator uses whatever sync information KMail uses to determine which items to 
add or delete. All other items get flags, attributes and full payload and the 
special attribute only lists things that have to be modified on the server, 
e.g. local unsynchronized payload changes.

Scenario 5: importing other client's maildir like storage into Akonadi 
maildir. For additional difficulty assume other client's storage has detached 
attachments (saved to separate local files)
similar to Scenario 1 but either reattaching files and sending respective 
payload parts (and setting special attribute appropriately) or linking to 
separate files using Nepomuk relations.

All special casing is handled by the migrator/importer, resources only need to 
understand the special attribute, e.g. the maildir resource can just 
acknowlegde item modifications that do not have payload part identifiers set 
in the attribute, because it doesn't store flags or attributes.

Mails downloaded by DIMAP don't have to be downloaded again, become available 
through Akonadi's cache and local changes not yet synchronized with the server 
get applied to the server without the IMAP resource understanding how KMail 
saved this state information.

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: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20100114/a3d2e9bb/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/