564765 - Migration and Import structure needs re-designing

Status: NEW

(MailNews Core :: Import, defect)

Description

[Mark Banner (:standard8)]

Currently we have:

mailnews/import
---------------

This is the main import code. This has its own UI for some aspects of import (e.g. settings, address book etc).

The worker code generally handles mainly import, but in the case of third party apps, also appears to handle migration.

mail/components/migration (or suite/profile/migration)
------------------------------------------------------

This is the main migration code. It has its own UI for providing the migration.

It is called from the mailnews/import code for "Import Everything". This is conceptually wrong as there's no flag to tell the migration assistant that it is importing and can lead to dataloss (bug 564162).

The UI also has options to act as an importer for specific subsets, e.g. in SeaMonkey the same code handles bookmarks import (into a running SM) and profile migration.

The code for 3rd party migration just calls into mailnews/import. The similar-app migration code is written in the migration component.


Proposed Rework/Redesign
------------------------

Single Migration UI
- Drop the UI code in mailnews/import. The migration controls both migration and import. Rework the existing migration code to allow importing of just address books, mail, settings etc.

Code restructure.
- I'm not sure if there is much that makes sense here without looking at the interfaces, but once the single migration UI is done, there may be sensible restructuring to do to better balance the mailnews/import and mail/components/migration back-end code.

Comment 1

[Ludovic Hirlimann [:Usul]]

Import/Migration doesn't carry much unit-tests, adding them while redesigning it would make regression catching with these portions of the code way easier and way faster.