On 03/01/2018 23:18, Nihanth Subramanya wrote:
++ from me as well, this sounds awesome.
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.
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”.
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++.
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.
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.
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:
Get an artifact build ready to go
Make changes, including adding the new observer topics to the manifest (or
list, or whatever you want to call it)
mach build faster
Changes are immediately testable, though there will be a perf cost unless you
do a “normal” build.
Yes, that seems right to me.
~ Gijs
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
