LivelyKernel / lively.modules

JavaScript package and module system for interactive development
8 stars 1 forks source link

System notifier for module and package events #22

Closed rksm closed 8 years ago

rksm commented 8 years ago

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.

  1. What kinds of events do we need? notifying about doits, module (un)loads, package loads, ...?
  2. What would a good interface to the notifier look like? How can notifications be submitted, how can dependents subscribe? There is currently a custom (un)subscribe mechanism which has the advantage of using ids for listeners so duplicated subscriptions can easily be avoided. Alternatively we could switch to nodejs-like event handlers that are available to us cross-platform via lively.lang/events.js.

Opinions?

/cc @tylervernonsmith @merryman

levjj commented 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.