Open Bug 41174 Opened 25 years ago Updated 3 years ago

mailnewsimport category stuff uses categories slightly wrong

Categories

(MailNews Core :: Profile Migration, defect, P3)

defect

Tracking

(Not tracked)

UNCONFIRMED

People

(Reporter: bruce, Unassigned)

Details

the mailnewsimport category stuff reverses the entry and the data when using the category manager. see bug #40248 for details. This is technically an API change for anyone writing importers I guess, so it'd be nice to have it fixed sooner rather than later.
I'm not sure I follow what's going on here. The basic structure is: ImportToolsCategory CLS-ID: string representing what formats this module supports The only thing that is unique is the CLS-ID, if I switch the entry to be the string and the data to be the CLS-ID then I wind up with something like this: ImportToolsCategory mail,address,settings: {XXXX..... -XXX} mail,address,settings: {YYYY..... -YYY} mail,address,settings: {xxxx..... -xxx} address: {blah-blah-blah} address: {ho-hum.....} etc. If this is more appropriate than having the CLS-ID's be the entry and the supports string being the value then I'll happily swap them but it seems odd to me to have a bunch of entries with the same name. (Unless I'm confusing which one is the entry and which one is the value!)
Hmmm. interesting. So, the data isn't more in the format of a textual string describing the importer mapping to a CID or ProgID? (The way the command line args handler operates is that some name for the component maps to the CID or ProgID, presenting a nice english way of determining what is what. But that assumes that things are unique, which doesn't sound like it is the case for you.) The only problem is that, with some new stuff that shaver is checking in/has checked in, his code will only work with things that store the CID/ProgID as the data rather than the entry (as I understand things).
What about multiple categories? mail-import-mail: name1 CID1 name2 CID2 name3 CID3 mail-import-addressbook: name2 CID2 mail-import-settings: name1 CID1 name3 CID3 (Do we want categories-in-categories? scc?) I think I need some more context on this stuff, though: how are these entries created? How are they registered?
All of these entries are created by an import module during xpcom registration. There is an import service that iterates the category to make import modules available to whomever requests them. The original concept for what a module supports (address, settings, mail) was/is intended to be extensible. For example, a UI component asks the import service for all of the import modules that support "address" to get a list of address book import modules. Same for mail and settings. Currently, the same import service could return modules that supported bookmarks or any other type of thing to import and the service and way that modules are registered wouldn't have to change. I sincerely doubt that we'll ever need to add things other than mail, address books and settings so it probably wouldn't be that big a deal to switch to multiple categories although it would make registering each individual module more of a pain. The reason for putting what a module supports rather than it's name in the category manager was so that lists of modules for particular import types could be build without having to load each individual module and ask what it supported.
It sounds like multiple categories is the way to go. If some future thing learns how to migrate something else (summary files? mail filters? newsgroup data?), then it would use another category for its capability, probably following the mail-import-* pattern. Though news-import-subscriptions makes more sense than mail-import-news-subscriptions. What about mailnews-import-addressbook, mailnews-import-mail-folders, mailnews-import-news-subscriptions? Thanks for the explanation!
OK. I'll switch it to multiple categories and use mailnews-import-* Is this something that can wait till the tree opens or do I need to mark it nsbeta2 or something like that to get approval to check it in when I make the change.
Whenever your change is done, check with waterson or brendan for approval. You probably don't need to rush to get it done before nsbeta2, but you certainly don't need to wait until the tree opens to check in a fix. Thanks!
Status: NEW → ASSIGNED
Any news about this change, Tony?
Product: MailNews → Core
QA Contact: agracebush → profile-migration
Product: Core → MailNews Core
Assignee: tonyr → nobody
Status: ASSIGNED → UNCONFIRMED
Ever confirmed: false
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.