Skip to content

Instantly share code, notes, and snippets.

@Gozala
Created August 17, 2010 21:54
Show Gist options
  • Save Gozala/532256 to your computer and use it in GitHub Desktop.
Save Gozala/532256 to your computer and use it in GitHub Desktop.

There are several well known & proved interfaces defined by w3c & acquiring those instead of inventing similar ones could benefit extension developers (specially newbies) a lot, since:

  1. They are already familiar with those interfaces.
  2. They may be able to reuse code across webapps & extensions.

Description of proposed API's:

  1. There is well known EventTarget / EventEmitter interface that is de facto standard on a web for processing events. It's also widely used by related popular platforms like: Flash & [node.js](node.js API's). Chrome's MessagePassing API's are also based on a very similar but slightly different Chrome's Events interface. Currently our listeners are populated in Collections by passing array / or function to a constructor or by calling add / remove methods on a collections. Think it would be better to switch to a mixed interface that will be a mix of EventTarget + EventDispatcher & EventEmitter. Library developers will also benefit from that since they will be able to just able to derive from EventEmitter and will no longer have to maintaining collections of event types. Prove of concept implementation can be found under the link

  2. ContentSymbiont provides a base building blocks for anything requiring message passing: PageWorker, PageMod, Panel, Sidebar etc. It's also likely to be used more cause it will be used for cross process communication. That being said again it would be very nice to have an API that devs are already familiar with to lower the gap of get into. W3C have defined WebWorkers & WebSockets interfaces that are very similar to a current [ContentSymbiont] implementations but slightly different. If we would just implement AbstractWorker interface from WebWorkers it will not only lower the time of learning, but potentially will allow to reuse / adapt already existing code. This change just requires small naming changes and derivation from above proposed EventEmitter interface, as a result we will end with a smaller and more objective specific implementation. Prove of concept & work in progress implementation can be found under the link

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment