On 04/01/2018 23:47, Gijs Kruitbosch wrote:
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.
Though of course, if we wanted to, we could decide that JS-only observer
topics should get their own mechanism/component entirely, which also
gets rid of this problem and avoids any xpconnect costs for this stuff,
at the cost of having 2 implementations publish/subscribe... But hey,
it's just a pub/sub implementation, not rocket science - and esp. in
JS-land I know the limitations of the observer service as-is in terms of
parameters etc. has been unfortunate at times.
~ Gijs
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
