Open Bug 396305 Opened 12 years ago Updated 12 years ago
Implement new eventing system
The existing event pump works alright mostly, but it suffers from speed issues when there are lots of hooks and isn't very plugin-friendly. What I'd like is something roughly based on the current system in terms of impl but: - Allows hooking events before *and* after the handler. - Allows overriding the handler of an event in a reversible manner. - Doesn't slow to a crawl when you add 5 hooks. ;) In particular, my thought is that we make the event pump use the knowledge of an event's set+type to optimise the look-up of hooks and handlers. E.g. if a hook specifies a set and type (as strings) we add it to a separate list of hooks for just that set+type rather than the global list. The main motivation for this is that I would like to make all the standard objects (ones defined in irc.js and co., i.e. CIRCNetwork, CIRCServer, CIRCUser, etc.) only have the onFooBar handlers in library code and NOT in the front-end code. Instead, the front-end code would only define hooks for specific set+type combinations, for the most part (hence the need for speed). The reversible handler override is mainly for plugins, which would be able to add their own handler for a particular set+type - the last one added wins, but any can be removed as well. To be clear: there would only ever be one *active* set+type handler (and thus, only one function would be called per set+type event), but it would be the first in a list of known handlers which could change at run-time as you enable/disable plugins. Note: I would like any new/changed API which defines/adds a hook or new handler override to always return an object/array which can be directly used in the undefine/remove API. Like the command manager does currently.
You need to log in before you can comment on or make changes to this bug.