On Wed, Jan 17, 2018 at 10:47 AM, Gabriele Svelto <gsve...@mozilla.com> wrote:
> 1) Introduce a new observer service that would live alongside the
> current one (nsIObserverService2?). This will use a machine-generated
> list of topics that will be held within the interface itself instead of
> a separate file as I originally proposed. This will become possible
> thanks to bug 1428775 [2]. The only downside of this is that the C++
> code will not use an enum but just integer constants. The upside is that
> this will need only one code generator and only one output file (the
> IDL) versus two generators and three files in my original proposal.
>
> 2) Migrate all C++-only and mixed C++/JS users to use the new service.
> Since the original service would still be there this can be done
> incrementally. Leave JS-only users alone.
>
> 3) Consider writing a JS-only pub/sub service that would be a better fit
> than the current observer service. If we can come up with something
> that's better than the observer service for JS then it can be used to
> retire the old service for good.
I'm not super-excited about having a split between C++/JS users and
JS/JS users. Besides the duplication of effort, I'm guessing that it
will be painful on the JS side. Which observer service do I use?
What if I suddenly find myself having C++ clients, do I have to
rewrite all previously JS-only-side callers? And so on.
Here's a very half-baked idea: what if the canonical location for
observer topics lived in JS? JS clients would make calls like:
Services.obs.notifyObservers(null, ObserverTopic.QuitApplication);
as described in the previous email, so they wouldn't have to care
about the particular type of ObserverTopic.QuitApplication and we'd
avoid the spelling errors that come with strings. We would have to
wrap the interface described below, so Services.obs would be some sort
of JS object that called into nsIObserverService2; nsIObserverService2
would not be used directly from client code. Under the hood, I think
we'd continue to use strings (unfortunately).
For non-artifact builds, we could generate some nice enumeration of
topics for C++ to use, as before. We'd also generate some sort of
mapping from string topic names to enum values, whose use will be
described below.
The XPIDL for this imaginary service would look something like:
[builtinclass, scriptable]
interface nsIObserverService2
{
[binaryname(NotifyObserversFromScript)]
void notifyObservers(in string topic, /* other parameters? */);
%{C++
void NotifyObservers(enum ObserverTopic, /* other parameters? */);
%}
[binaryname(AddObserverFromScript)]
void addObserver(in string topic, /* other parameters? */);
%{C++
void AddObserver(enum ObserverTopic, /* other parameters? */);
%}
/* and similarly for everything else required */
}
The AddObserverFromScript implementation would look something like:
if (topic maps to an enum value) {
AddObserver(enum value, ...);
} else {
/* add observer to separate hashtable mapping string topics to
observer lists, the way nsObserverService works today */
}
NotifyObserversFromScript would work the same way: we'd see if we knew
about this string topic, and then that determines which hashtable we'd
consult. Having the string fallback means that newly-added topics for
artifact builds work. This still duplicates effort, but at least
everybody is using the same interface. And things added solely for
JS's usage are silently incorporated into the enum version at the next
full build.
This has the downside of not using integers quite everywhere, so
JS->C++ calls haven't been reduced much in cost. The extra layer of
object proxying on the JS side might also make things more expensive.
I don't know what to do about that, but some cleverness on the JS side
could make it so we used integers for "known" things and strings for
"artifact" things, perhaps by asking the C++ layer at startup or
something.
Does that proposal make sense? WDYT?
-Nathan
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
