Closed Bug 952182 Opened 11 years ago Closed 10 years ago

CUI should dispatch observer notifications instead of making yet another event listener API

Categories

(Firefox :: Toolbars and Customization, defect)

defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: irakli, Unassigned)

References

(Blocks 1 open bug)

Details

It would be very nice if CUI exposed it's events using observer service instead of
introducing another event listening API. For example in SDK we have a code that takes care of unresisting all listeners when add-on is unloaded, but not doing it actually when add-on is unloaded because of shutdown (to not slow shut down) etc... It's pretty much battle tested at this point. It would be great to leverage
existing infrastructure instead of duplicating it with a risk to leak listeners
or introduce some other bugs.
The Downloads manager and various other APIs do the same thing, effectively to be able to easily group similar notifications on the same object without the switch statement mess. I don't think we should change this, but I'll leave it to Jared/Blair to make a decision.
Flags: needinfo?(jaws)
Flags: needinfo?(bmcbride)
OS: Mac OS X → All
Hardware: x86 → All
Version: 26 Branch → Trunk
I'm not inclined to change this, it seems like a lot of change without an equal benefit.
Flags: needinfo?(jaws)
We had discussed this on IRC before the break - it's a no-go. One primary reason is simply of performance - we fire many events, and we have a few tight loops we need to keep performant that involve numerous events. Involving the observer service, with going back and forth over the XPConnect boundary, would kill performance for us. Another is that observer notifications are generally *harder* for people to use; the API we have at the moment isn't new (it's a common pattern throughout the tree), it's self documenting, and it's better suited to JS.

One alternative we discussed on IRC would be in investing into building a JS event bus module that we could use here and in all other similar situations (in browser and toolkit) - providing a known stable generic API. But, that shouldn't be a blocker.
Status: NEW → RESOLVED
Closed: 10 years ago
Flags: needinfo?(bmcbride)
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.