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.
https://bugzilla.mozilla.org/show_bug.cgi?id=1425909 is hitting the same issue with telemetry probes. 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. Nick On Thu, Jan 18, 2018 at 2:47 AM, Gabriele Svelto <gsve...@mozilla.com> wrote: > Hello all, > I've tried to take into account all the suggestions from the discussion > of my previous proposal [1] and I've come up with a new plan which > should cover all bases. Don't hesitate to point out things that might > still be problematic, since this is going to be a large refactoring it's > better to get it right from the start. > > The biggest sticking point of my previous proposal was that it would > prevent any modifications to the observer list from artifact builds. > Addressing that particular issue effectively requires to keep the > existing service in place so instead of replacing it altogether I'd do > the following: > > 1) Introduce a new observer service that would live alongside the > current one (nsIObserverService2?). This will use a machine-generated > list of topics that will be held within the interface itself instead of > a separate file as I originally proposed. This will become possible > thanks to bug 1428775 [2]. The only downside of this is that the C++ > code will not use an enum but just integer constants. The upside is that > this will need only one code generator and only one output file (the > IDL) versus two generators and three files in my original proposal. > > 2) Migrate all C++-only and mixed C++/JS users to use the new service. > Since the original service would still be there this can be done > incrementally. Leave JS-only users alone. > > 3) Consider writing a JS-only pub/sub service that would be a better fit > than the current observer service. If we can come up with something > that's better than the observer service for JS then it can be used to > retire the old service for good. > > So, how does this sound? > > Gabriele > > [1] > https://lists.mozilla.org/pipermail/dev-platform/2018-January/020935.html > [2] Make it possible to generate IDL files > https://bugzilla.mozilla.org/buglist.cgi?quicksearch=1428775 > > > _______________________________________________ > firefox-dev mailing list > firefox-...@mozilla.org > https://mail.mozilla.org/listinfo/firefox-dev > > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
