This project is read-only.

Notification Events

A generic way of notifying of changes must be devised in order for both plugin and host to register for - and respond to notification events.

There are several levels of notification events:
- A Service has become available or unavailable.
- A collection has changed.
- An object (properties) has changed.

For some scenario it would be best to explicitly define a way to receive these events and how to subscribe for them. Other times it might be best to use a generic mechanism.

A generic way for notifying collection and object changes is by using the INotifyPropertyChanged and the INotifyCollectionChanged interfaces already present in the .NET framework. These interface provide events for both scenarios.

Another generic way is a publish subscribe mechanism (service). In this case a publisher advertises an event and the parameters that come with it (as a public class - normal code dependency). The Publish-Subscribe Service is the middle-man between the publisher of the event and the subscribers of the event. The subscribers express their interest by registering a callback function with the Publish-Subscribe Service for a specific event. These subscriptions may even be filtered (only call me when the value is above 100 for instance). When a subscriber is no longer interested in the event it simply unsubscribes from the Publish-Subscribe Service.

Through the Plugin Context there is a natural scope/reach on which these events and subscriptions act. At first glance it does not seem useful to have Plugins publish events to other plugins. Only the host can subscribe to plugin events and the host determines what plugin subscriptions get called (either by plugin context or subscription-filtering) when it publishes an event. Some host events would need to be distributed to all plugins, some may only be useful to a (sub) graph or one specific plugin.

A specific way to implement notification events is to add the event to the specific (service) interface or pass a callback function as a method parameter.

A plugin can also indicate (profile) that it would like to send and/or receive certain events in a streaming fashion during processing. A specific list of events can be supported by the host. If a plugin sends event of a type not supported by the host, but it IS supported by a down-stream plugin, the host merely passed these events onto the next plugin that supports them.

Note: How any of these translate to C++ remains to be seen.

Last edited Oct 9, 2013 at 3:14 PM by obiwanjacobi, version 2