Closed rksm closed 8 years ago
I'm currently using subscriptions via notify.js
and that seems to work fine for a local system, so maybe we don't have to change that much.
I think the most important events would be
I also like the idea of just using one lively.lang/events.js event-emitter per "system". There could be multiple systems (local and remote) but each should allow the same operations and subscriptions.
One more thing: It would be great if subscriptions were weak references. So, if the subscribing object becomes garbage, it can be collected and the subscriptions removed. JavaScript has WeakMap and WeakSet but I don't think we can use these to make subscriptions weak.
As @levjj pointed out in #20 we need a notification mechanism for changes of the module, package, and System state. Main use for the notifications would be tools that depend on lively.modules, e.g. when having multiple browsers open, one browser changes the definition of a module then the other browsers (might) need to update their views.
notify.js has a first implementation of a notification system currently this is only used for module changes change.js.
Let's make a list of use cases from which we can deduct what functionality the notifier needs to include.
Opinions?
/cc @tylervernonsmith @merryman