Re: Refactoring proposal for the observer service

2018-01-04 Thread Gijs Kruitbosch
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=false=false= -- sync, the add-ons manager, session store,

Re: Refactoring proposal for the observer service

2018-01-04 Thread Gijs Kruitbosch
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=false=false= -- sync, the add-ons manager, session store, etc. etc.). That's not exactly what I meant. JS

Re: Refactoring proposal for the observer service

2018-01-04 Thread Gabriele Svelto
On 04/01/18 22:47, Nathan Froyd wrote: > This is very doable, it just requires some build system hackery: we > accept preprocessed/generated WebIDL files, and generated IDL files > would require basically the same approach. I can help with the build > system hackery if you want to continue

Re: Refactoring proposal for the observer service

2018-01-04 Thread Nathan Froyd
On Thu, Jan 4, 2018 at 4:44 PM, Gabriele Svelto wrote: > On 04/01/18 22:39, Ben Kelly wrote: >> Or make your "generator" >> create the idl which then creates the js/c++? > > I tried as that could have worked! Unfortunately it doesn't seem to be > possible ATM. mach bailed

Re: Refactoring proposal for the observer service

2018-01-04 Thread Gabriele Svelto
On 04/01/18 22:39, Ben Kelly wrote: > We can't have a comment explaining "please add any new constants in > sequential order in the following list"? We could, but what about removing one? Also if we have hundreds (or thousands) the risk that one is accidentally duplicated is significant. My

Re: Refactoring proposal for the observer service

2018-01-04 Thread Ben Kelly
On Thu, Jan 4, 2018 at 4:35 PM, Gabriele Svelto wrote: > On 03/01/18 23:30, Ben Kelly wrote: > > Could we use our existing idl/webidl/ipdl for this? It would be nice > > not to have to maintain another code generator in the tree if possible. > > > AFAIK there is no way in

Re: Refactoring proposal for the observer service

2018-01-04 Thread Gabriele Svelto
On 03/01/18 23:30, Ben Kelly wrote: > Could we use our existing idl/webidl/ipdl for this?  It would be nice > not to have to maintain another code generator in the tree if possible. AFAIK there is no way in IDL to declare an enum. Constants can be declared but one needs to manually assign them a

Re: Refactoring proposal for the observer service

2018-01-04 Thread Matthew N.
On 2018-01-04 10:00 AM, Nathan Froyd wrote: … 2) How would one shoehorn this into *DL? The options that come to mind are: - Separate methods for every observer topic, which sounds terrible from a code duplication perspective. Though maybe this would be nice for JS clients, so we could say

Re: Refactoring proposal for the observer service

2018-01-04 Thread Ben Kelly
On Thu, Jan 4, 2018 at 10:00 AM, Nathan Froyd wrote: > On Wed, Jan 3, 2018 at 5:30 PM, Ben Kelly wrote: > > On Wed, Jan 3, 2018 at 5:09 PM, Gabriele Svelto > wrote: > >> So after validating my approach in that bug (which is almost

Re: Refactoring proposal for the observer service

2018-01-04 Thread Nathan Froyd
On Wed, Jan 3, 2018 at 5:30 PM, Ben Kelly wrote: > On Wed, Jan 3, 2018 at 5:09 PM, Gabriele Svelto wrote: >> So after validating my approach in that bug (which is almost ready) I've >> thought that it might be time to give the observer service the same >>

Re: Refactoring proposal for the observer service

2018-01-04 Thread Gijs Kruitbosch
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"

Re: Refactoring proposal for the observer service

2018-01-03 Thread smaug
On 01/04/2018 12:30 AM, Ben Kelly wrote: On Wed, Jan 3, 2018 at 5:09 PM, Gabriele Svelto wrote: So after validating my approach in that bug (which is almost ready) I've thought that it might be time to give the observer service the same treatment. First of all we'd have a

Re: Refactoring proposal for the observer service

2018-01-03 Thread Gijs Kruitbosch
This is really interesting, thanks for looking at this! On 03/01/2018 22:09, Gabriele Svelto wrote: This would have quite a few coding benefits: - It would make it far easier to retire/rename a topic, since ... JS would throw. Why would it? I think it would pass undefined (as the topic

Re: Refactoring proposal for the observer service

2018-01-03 Thread Ben Kelly
On Wed, Jan 3, 2018 at 5:09 PM, Gabriele Svelto wrote: > So after validating my approach in that bug (which is almost ready) I've > thought that it might be time to give the observer service the same > treatment. First of all we'd have a list of topics (I've picked YAML for

Re: Refactoring proposal for the observer service

2018-01-03 Thread Botond Ballo
On Wed, Jan 3, 2018 at 5:09 PM, Gabriele Svelto wrote: > - It would make trivially simple to document the topics, their subjects > and payloads. Potentially this could even be integrated with our > generated documentation and code search tools making developer lives a > lot

Re: Refactoring proposal for the observer service

2018-01-03 Thread David Teller
That would be great! On 03/01/18 23:09, Gabriele Svelto wrote: > TL;DR this is a proposal to refactor the observer service to use a > machine-generated list of integers for the topics (disguised as enums/JS > constants) instead of arbitrary strings. >