See also: OATC Wiki Home

Date: July 6, 2010
Time: 16:00 - 17:00 CEST
Venue: Skype Conference Call
Topic: Extendable version of OpenMI 2 (continued)

Table of contents

Participants

Standa Vanecek, DHI (s.vanecek@dhi.cz)
Adrian Harper, Wallingford Software (adrian.harper@wallingfordsoftware.com)
Stef Hummel, Deltares (stef.hummel@deltares.nl)
~jgr@dhigroup.com, DHI (jgr@dhigroup.com)
Peter Schade, Bundesanstalt fuer Wasserbau (peter.schade(at)baw.de)

Apologies:
Rob Knapen, Alterra, Wageningen UR (Rob.Knapen@wur.nl)
~don, Deltares (gennadii.donchyts@deltares.nl)

1. Progress towards OpenMI 2 Beta release

1.1. Source code update status - C#

1.2. Source code update status - Java

1.3. Documentation updates

Decision from meeting 31: Standa made a Word *.doc out of the reviewers' feedback. The suggestions that have been integrated in OpenMI 2 will be indicated. The new document will be put on the wiki / www.openmi.org in order to display that the feedback was indeed valuable.

1.4. Observations during working with the new standard

(Jesper) IDescribable has both setter and getter for Caption and Description, though these are I guess not really settable for others than the mother component. I have had to put in a number of "NotSupportedException" for the setter. Remove the setter?

(Jesper) In 1.4 there was an event mechanism that could be used to propagate warnings from the engine to the OpenMI system (configuration editor etc). Now there is a StatusChanged event, which is much more specific. Being not a super-user of the OpenMI components, is it usefull to have such warnings from the engine in e.g. the configuration editor GUI or elsewhere? In that case maybe there should be a general purpose event on the IBaseLinkableComponent.

(Jesper) Where does the old EarliestNeededTime go? To the ITimeSpaceComponent.TimeExtent, or to each of the input items time extent?

2. Ongoing discussion topics

2.1. How to package and distribute extensions; already decided?

(Rob) When an extension is approved by OATC will it be included into the Standard library (dll or jar), or will each extension be distributed in its own library?

(Peter) To keep it in the standard library will make the check on compliancy easier, s. 2.1.2. saying compliant models have to reference OpenMI2.Standard.dll/jar. One argument pro an own library is that new extensions can be more frequently updated than the standard. Anyway, I guess the OAEC has to decide formally about new extensions as it did about compliancy of models in the past.

(Jesper) I believe (at least for C#, I am not sure with java) when we first have released the OpenMI2.Standard.dll, then there are issues in case this dll is updated to include e.g. a dictionary extension: Two different OpenMI2.Standard.dll files having the same version number, but different content. It would be much more safe to release an OpenMI2.Standard.DictionaryExtension.dll, and leaving the original content in the OpenMI.Standard.dll. It may be possible to put it all in a new standard dll, however that requires "intelligent" installers: Assume I am to install a TimeSpace engine and a Dictionary engine, which come with each their version of the OpenMI2.Standard.dll that they want to install and register in the GAC. Depending on the order in which I install the engines, each installer needs to know whether they are to reregister their version of the OpenMI2.Standard.dll in the GAC, to assure that the newest version is the one registered.

2.2. Revisit discussions left out from meeting 28

There is a number of discussions there, that has not yet been decided on.