<div dir="ltr"><br><div><div class="gmail_extra"><div class="gmail_quote">On Thu, Jan 4, 2018 at 6:51 PM, Gijs Kruitbosch <span dir="ltr"><<a href="mailto:gijskruitbosch@gmail.com" target="_blank">gijskruitbosch@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 04/01/2018 23:47, Gijs Kruitbosch wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 04/01/2018 22:49, Gabriele Svelto wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 04/01/18 00:05, Gijs Kruitbosch wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Unfortunately, there are quite a lot (<br>
<a href="https://searchfox.org/mozilla-central/search?q=obs.addObserver&case=false&regexp=false&path=" rel="noreferrer" target="_blank">https://searchfox.org/mozilla-<wbr>central/search?q=obs.addObserv<wbr>er&case=false&regexp=false&pat<wbr>h=</a> <br>
-- sync, the add-ons manager, session store, etc. etc.).<br>
</blockquote>
That's not exactly what I meant. JS clients are fine as long as the<br>
topic has already been declared. The issue with artifact builds arises<br>
only when adding an entirely new topic that is used only in JS code<br>
(i.e. both the notifier and listener are JS-only). I don't know how many<br>
patches we've had but my guess is that they're not that many. JS code<br>
usually has better ways to deal with this kind of scenarios than using<br>
the observer service.<br>
</blockquote>
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.<br>
</blockquote>
<br></span>
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.</blockquote><div><br></div><div>A JS-only observer mechanism would be very nice (especially if it were async friendly, not that I really know what exactly that would look like), but unless there's either A) easy interop between it and the existing system, or B) we make an effort to transition JS-only observers from the existing system to the JS-only system shortly after adding it, I think it would likely be worse than the status quo.</div><div><br></div><div>Really, both A and B would probably be necessary for it not to be a headache in practice...<br></div></div></div></div></div>