Problem

IEvent.Sender currently (Standard version 1.x) is defined as an ILinkableComponent, so only linkable components can be the source of (OpenMI) events. This limits the use of the OpenMI event mechanism and of the seperate IPublisher interface.

Proposal

Change the IEvent.Sender to be an IPublisher. ILinkableComponent already extends this interface, and this way other objects could do as well and make use of the OpenMI event mechanism. The other option is to make the OpenMI event mechanism really ILinkableComponent specific, i.e. rename IEvent to ILinkableComponentEvent and get rid of the public visible IPublisher interface.

For the 2.x release it would be good to look how these OpenMI events could be mapped better onto the event mechanisms of the supported languages (C# and Java).

Adventages

Disadvantages

Examples

Too obvious to mention.
  • No labels

2 Comments

  1. Jan Gregersen

    I do not think that Examples are too obvious to mention. So far we have avoided changing the OpenMI standard interfaces, and we need very good reasons to do so before we release version 2. So, I would appreciate an example demonstrating what exactly is not possible with the current IPublisher interface. I understand that, e.g. a link cannot send an event, because it is not a LinkableComponent. But why should the link send an event, and why should the link use the OpenMI event type and not any other event mechanism? The OpenMI event mechanism was developed with a specific use in mind, namely to enable linkable components to publish information about their state (e.g. the linkable component is at a state where it has invoked the GetValues in another linkable component). If you look at the defined event types, this is very clear. If you look at the IPublisher interface you will also see a property called SimulationTime, which only makes sense for models. I know that we currently are seeing linkable components in a broader context (they can be other things than models), but if you look through the OpenMI standard version 1 interfaces, you will see many examples of things that only makes sense for models. So in conclusion, I think that the event, is just one of many things that needs to be changed, so let's leave it as it is and make this change along with all the other things in OpenMI version 2.

  2. Rob Knapen

    What you mention is the obvious example (smile) An implementation of a link that does some kind of data buffering would be a good candidate to sent events so that e.g. it can be monitored. Which is one of the goals of the event mechanism ("to enable troubleshooting and facilitate development of monitoring and visualisation tools" (OpenMI Standard Specification)). If this could be done with the OpenMI event type and not some other type of events, a GUI does not have to subscribe to different types of events to monitor different (OpenMI) objects.

    Another possible example is to make a ValueSet that implements IPublisher so that it can sent OpenMI events about data changes. Visualisations tools could listen to this to update the display accordingly, avoiding the need of having to deal with different types of events (and mechanisms).

Disclaimer