Exposes a composable event emitter for low level usage let { events } = require('sdk/places/events'); events.on('bookmark-item-added', handler); filter(events, ({type}) => /bookmark/.test(type)).on('data', handler);

Made all the changes from the PR, other than the event naming stuff. We should decide if these are `on(events, 'data', () => )` or `on(events, 'bookmark-item-added', () =>)`. One is easier for composability, and the other for one-off event listeners. Either way, we should stick to one while moving forward if we have to limit it to one, as both styles are used the SDK currently.

I take it back -- we should have 'data' events for the low level API, and for the high-level abstraction in the bookmark/history module, just have `require('sdk/places/bookmarks').on('bookmark-item-added', () =>)`

Comment on attachment 781939 [details] GH PR 1136 Resubmitting, using 'data' events as low level events, and we can use another abstraction for high level ones when implemented

Comment on attachment 781939 [details] GH PR 1136 Proposed some suggestions, but don't feel very strong about them.

Commits pushed to master at https://github.com/mozilla/addon-sdk https://github.com/mozilla/addon-sdk/commit/8619846226471f7ca083eeb591864ef9b1f177fe Bug 885667 Implement places events https://github.com/mozilla/addon-sdk/commit/85b586b0f087be611bfb6517e22aae649b5474e5 Merge pull request #1136 from jsantell/places-events Fix Bug 885667, places events, r=@gozala