<div dir="ltr">I don't know if this has been considered, but for artifact builds we could just keep a handful of temporary observer topics around that can be used to quickly build things, and then replaced with real new observer topics when it comes time to land it. Might be a bit ugly, but we wouldn't have to build and maintain a JS-only forwarder.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 4, 2018 at 3:06 AM, 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 class="">On 03/01/2018 23:18, Nihanth Subramanya wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
++ from me as well, this sounds awesome.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Ideally, I would like a solution where especially JS-only observer topics don't require a non-artifact build. A JS forwarder for the "real" observer service may help with that goal, by making the "new" arguments into strings transparently, and using the same string as a webidl name property for artifact builds. This would mean "new" JS-only observer calls in an artifact build would be slower than the int-based "real" ones (and would perform "normally" once you actually did a "real" build, ditto for distributed stuff). I think that's an OK trade-off.<br>
</blockquote>
Would you mind expanding on how you see this working? Specifically, I didn’t understand "using the same string as a webidl name property for artifact builds”.<br>
</blockquote></span>
We'd have a JS artifact-build-only version of the topics list that was a proxy on the 'real' thing. So you'd access ObsTopics.Foo, and if the 'real' thing knew about "Foo", it'd just forward the relevant int. If not, it would return the topic string (so "Foo"). When the JS forwarder for the 'real' service gets called with a string (instead of an int), it notifies/adds/removes observers on itself only, and doesn't pass the relevant call to C++.<br>
<br>
The reason for using strings and forwarding is that I don't see a reasonable way for the build system to distinguish topics that the binary blobs it's using know about, from topics they have no idea about (that the developer just added to the manifest). Whereas at runtime it's easy to make that determination. I guess you could maybe do it at build time by firing up xpcshell as part of the build process, and then generate new ints for the new topics into the JS file, but that seems cumbersome at best.<br>
<br>
Plus you'd probably want to make the observer service throw for calls with invalid topic ints, so then you need a way to distinguish the new JS-only ones on the JS side before passing it to the 'real' observer service. I guess we could have the C++ side expose the "maximum valid topic int" or whatever, and the JS side could check that... but having them be different JS types seems simpler.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Also related: in this JS forwarder world you’re describing, what exactly does the workflow look like for a frontend developer using artifact builds? I’d imagine the following:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Get an artifact build ready to go<br>
Make changes, including adding the new observer topics to the manifest (or list, or whatever you want to call it)<br>
mach build faster<br>
Changes are immediately testable, though there will be a perf cost unless you do a “normal” build.<br>
</blockquote></blockquote></span>
Yes, that seems right to me.<span class="HOEnZb"><font color="#888888"><br>
<br>
~ Gijs</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
______________________________<wbr>_________________<br>
firefox-dev mailing list<br>
<a href="mailto:firefox-dev@mozilla.org" target="_blank">firefox-dev@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/firefox-dev" rel="noreferrer" target="_blank">https://mail.mozilla.org/listi<wbr>nfo/firefox-dev</a><br>
</div></div></blockquote></div><br></div>