<div dir="ltr"><div>I have similar issues with some changes to prefs that I am planning. I too am probably going to end up with a split implementation, with "good prefs" (faster, better) for C++ usage and "crappy prefs" (the current implementation) for JS usage.</div><div><br></div><div><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1425909">https://bugzilla.mozilla.org/show_bug.cgi?id=1425909</a> is hitting the same issue with telemetry probes.</div><div><br></div><div>In short, I know that front-end devs love artifact builds dearly, but they are a significant constraint for these components that have longs lists of things being tracked. It's a bit frustrating.<br></div><div><br></div><div>Nick<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 18, 2018 at 2:47 AM, Gabriele Svelto <span dir="ltr"><<a href="mailto:gsvelto@mozilla.com" target="_blank">gsvelto@mozilla.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Hello all,<br>
I've tried to take into account all the suggestions from the discussion<br>
of my previous proposal [1] and I've come up with a new plan which<br>
should cover all bases. Don't hesitate to point out things that might<br>
still be problematic, since this is going to be a large refactoring it's<br>
better to get it right from the start.<br>
<br>
The biggest sticking point of my previous proposal was that it would<br>
prevent any modifications to the observer list from artifact builds.<br>
Addressing that particular issue effectively requires to keep the<br>
existing service in place so instead of replacing it altogether I'd do<br>
the following:<br>
<br>
1) Introduce a new observer service that would live alongside the<br>
current one (nsIObserverService2?). This will use a machine-generated<br>
list of topics that will be held within the interface itself instead of<br>
a separate file as I originally proposed. This will become possible<br>
thanks to bug 1428775 [2]. The only downside of this is that the C++<br>
code will not use an enum but just integer constants. The upside is that<br>
this will need only one code generator and only one output file (the<br>
IDL) versus two generators and three files in my original proposal.<br>
<br>
2) Migrate all C++-only and mixed C++/JS users to use the new service.<br>
Since the original service would still be there this can be done<br>
incrementally. Leave JS-only users alone.<br>
<br>
3) Consider writing a JS-only pub/sub service that would be a better fit<br>
than the current observer service. If we can come up with something<br>
that's better than the observer service for JS then it can be used to<br>
retire the old service for good.<br>
<br>
So, how does this sound?<br>
<br>
 Gabriele<br>
<br>
[1]<br>
<a href="https://lists.mozilla.org/pipermail/dev-platform/2018-January/020935.html" rel="noreferrer" target="_blank">https://lists.mozilla.org/<wbr>pipermail/dev-platform/2018-<wbr>January/020935.html</a><br>
[2] Make it possible to generate IDL files<br>
    <a href="https://bugzilla.mozilla.org/buglist.cgi?quicksearch=1428775" rel="noreferrer" target="_blank">https://bugzilla.mozilla.org/<wbr>buglist.cgi?quicksearch=<wbr>1428775</a><br>
<br>
<br>______________________________<wbr>_________________<br>
firefox-dev mailing list<br>
<a href="mailto:firefox-dev@mozilla.org">firefox-dev@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/firefox-dev" rel="noreferrer" target="_blank">https://mail.mozilla.org/<wbr>listinfo/firefox-dev</a><br>
<br></blockquote></div><br></div>