On 04/01/2018 22:49, Gabriele Svelto wrote:
On 04/01/18 00:05, Gijs Kruitbosch wrote:
Unfortunately, there are quite a lot (
https://searchfox.org/mozilla-central/search?q=obs.addObserver&case=false®exp=false&path=
-- sync, the add-ons manager, session store, etc. etc.).
That's not exactly what I meant. JS clients are fine as long as the
topic has already been declared. The issue with artifact builds arises
only when adding an entirely new topic that is used only in JS code
(i.e. both the notifier and listener are JS-only). I don't know how many
patches we've had but my guess is that they're not that many. JS code
usually has better ways to deal with this kind of scenarios than using
the observer service.
But the examples I gave are exactly that. sync, the add-ons manager and
sessionstore all live in JS-land and have, to the best of my knowledge,
(almost?) no C++ consumers of their "own" observer notifications. And
they all have several observer notifications. They are also not the only
components that do this, just the first few I spotted in the searchfox
query.
Ideally, I would like a solution where especially JS-only observer
topics don't require a non-artifact build.
I've given this a little thought and there could be a simpler solution,
though a little hacky. Instead of making the number of topic a
compilation constant one could put it somewhere were it could be
discovered at runtime (such as a preference) then leave a few empty
slots in the table for "unexpected" observers. In an artifact build one
would add the new topic which would regenerate the JS code, update the
number of topics but not the C++ side. At runtime C++ code would then
see the "unexpected" topic but since it would still end up in the
expected range at runtime would handle it correctly.
It wouldn't be super-pretty but it would work for common cases such as
adding only one new topic (or a few).
Well, I assume we ideally want the file to be organized. Not willy-nilly
collections of "useful observer topics", like the way in which all.js
and Histograms.json are basically a giant mess. I would further assume
that we (automatically) number items sequentially. So adding items in
the middle of the list and not recompiling the C++ is going to cause
off-by-N errors for however many N observers you add, right? I don't see
a good way of distinguishing the "new" topics at build-time and
numbering them differently. Of course, patches could add the topic at
the end for testing and then move it for review/landing, but that's
still going to be annoying for developers, esp. if there's multiple
review cycles, and we'll probably forget to do it sometime, etc. etc. So
not very ergonomic...
~ Gijs
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
