bugzilla.mozilla.org will be intermittently unavailable on Saturday, March 24th, from 16:00 until 20:00 UTC.

mailnewsimport category stuff uses categories slightly wrong

Assigned to


MailNews Core
Profile Migration
18 years ago
10 years ago


(Reporter: Bruce Mitchener, Assigned: tonyr)


Firefox Tracking Flags

(Not tracked)




18 years ago
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.

Comment 1

18 years ago
I'm not sure I follow what's going on here.  The basic structure is:


    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:


    mail,address,settings: {XXXX..... -XXX}

    mail,address,settings: {YYYY..... -YYY}

    mail,address,settings: {xxxx..... -xxx}

    address: {blah-blah-blah}

    address: {ho-hum.....}


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!)   


Comment 2

18 years ago
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?

  name1  CID1
  name2  CID2
  name3  CID3

  name2  CID2

  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?

Comment 4

18 years ago
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!

Comment 6

18 years ago
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.



18 years ago

Comment 8

14 years ago
Any news about this change, Tony?
Product: MailNews → Core


10 years ago
QA Contact: agracebush → profile-migration
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.