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)
MailNews Core
Profile Migration
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!)
| Reporter | ||
Comment 2•25 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).
Comment 3•25 years ago
|
||
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.
Comment 5•25 years ago
|
||
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.
Comment 7•25 years ago
|
||
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!
Updated•21 years ago
|
Product: MailNews → Core
Updated•17 years ago
|
QA Contact: agracebush → profile-migration
| Assignee | ||
Updated•17 years ago
|
Product: Core → MailNews Core
Updated•5 years ago
|
Assignee: tonyr → nobody
Status: ASSIGNED → UNCONFIRMED
Ever confirmed: false
Updated•3 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•