161814 - Eliminate nsICharsetConverterManager (replace with nsICharsetConverterManager2)

Status: RESOLVED DUPLICATE of bug 206379

(Core :: Internationalization, defect, P2)

Description

[Boris Zbarsky [:bzbarsky]]

As far as I can tell, the only reason we use nsICharsetConverterManager anywhere
is because people just have not bothered to move to nsICharsetConverterManager2.
 I think it's nigh time to do that, so that we only have one interface to deal with.

I've cced the people I can think of who I'm pretty sure need to know about this
and have input into it.  If I missed someone who should be cced on this bug,
please cc them.  I'm not trying to do anything sneaky here.  ;)

Comment 1

[Darin Fisher]

sounds like a good plan to me... perhaps you could convert the interface over to
use the abstract string classes while you're at it ;-)

Comment 2

[Rui Xu]

code issue, QA to [e-mail] for now.

Comment 3

[Alec Flett]

yes, please do! Also, if I recall correctly the only reason that
nsICharsetConverterManager takes UCS2 charset names is for passing names to
string bundles to find charset aliases - but most of the time it wants ASCII
names. Lets make the interface implement just ASCII (i.e. not
GetCharsetAtom2/etc) and make the callers optimize their code around that

Thanks to the duel API, we have a mix of ASCII and UCS2 charset names all over
the tree and nobody is sure which one is the right one.

Comment 4

[Darin Fisher]

here here!  ;-)

Comment 5

[Boris Zbarsky [:bzbarsky]]

Alec, it looks like your patch in bug 206379 basically resolves this bug... if
so, please mark duplicate?

Comment 6

[Alec Flett]

yep

*** This bug has been marked as a duplicate of 206379 ***