On 11/11/2013 10:23 AM, Henri Sivonen wrote:
In principle, the right way to deal with this would be moving code to
comm-central. However, this would involve annoyances like setting up a
new XPCOM component there and making sure the category manager merges
m-c-defined and c-c-defined category entries correctly. Considering
the de-emphasis on Thunderbird as far as Mozilla-paid development time
goes, it seems unlikely that Thunderbird developers would do the work
soon. On the other hand, looking at this as a Gecko developer, getting
rid of this code in Firefox builds seems like a legitimate way to use
time, but importing the code into comm-central seems less so.
Why don't we remove them from core and let tbird devs deal with it when
they do have time (or stop supporting UTF7 and so forth if it's not
important enough to fix)? If these character converters aren't needed as
part of the web platform, the projects that do need them should be
paying the costs for them.
FWIW, unless I don't understand how this uses the category manager, I
doubt that merging would be a problem, and this doesn't sound like a
large task for Thunderbird volunteers to take the code we're removing
from m-c and port it to c-c.
By far the easiest solution would be leaving the code in m-c but
#ifdefing it out of Firefox builds. Is there a compelling reason not
to do so? If there is no compelling reason against #ifdefing it out in
m-c, what's the right variable to #ifdef on (needs to work in
moz.build and the preprecessor)?
I'm not certain whether tbird (and seamonkey) are currently using a
shared XULRunner in Linux distros. If they are, then this approach won't
work well (we'd at least have to continue disabling these encodings via
prefs in Firefox). I don't think that we should be doing the extra pain
of ifdefs for this case.
--BDS
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
