| scrollbar |
|---|
See also: OATC Wiki Home
Date: June 18, 2010
Time: 09:00 - 10:00 am
Venue: Skype Conference Call
Topic: Extendable version of OpenMI 2
Participants:
Rob Knapen, Alterra, Wageningen UR (Rob.Knapen@wur.nl)
Standa Vanecek, DHI (s.vanecek@dhi.cz)
Adrian Harper, Wallingford Software (adrian.harper@wallingfordsoftware.com)
Stef Hummel, Deltares (stef.hummel@deltares.nl)
~don Unknown User (don), Deltares (gennadii.donchyts@deltares.nl)
~jgr@dhigroup.com, DHI (jgr@dhigroup.com)
Table of contents
...
This is a discussion page on making the OpenMI 2 Standard more extendable, which was discussed during the Skype conference call. Decisions made during the meeting are marked as 
or 
, with additional comments in italics where needed. You can find these (mostly) in the discussion section at the end of the page.
The general idea is to include a few base interfaces and separate the core OpenMI aspects from the time and space dimensional aspects. In OpenMI 1 both are combined in the interfaces making it difficult to create extensions that allow use of OpenMI in domains that have other dimensionality requirements. Another goal is to allow postponing of some of the more difficult and time consuming functionality (to define, build and test) like support for parallel computing and OGC compliant element sets, to OATC approved extensions to the basic OpenMI 2 Standard.
...
All work to be done in the SourceForge OpenMI-2.0.0-extendable branch: http://openmi.svn.sourceforge.net/viewvc/openmi/branches/OpenMI-2.0.0-extendable/
Meeting Decision: Code will be moved to the main trunk folder (Jesper).
Component | Update | Component | Update? | update author | author deadline | reviewer | deadline |
|---|---|---|---|---|---|---|---|
C# OpenMI 2 Standard | y/n | who | 28. June | who | 2. July | ||
C# OpenMI 2 SDK | y/n | who | 28. June | who | 2. July | ||
C# OpenMI 2 GUI | y/n | who | 28. June | who | 2. July | ||
Java OpenMI 2 Standard | y/n | Rob | 28. June | who | 2. July | ||
Samples to test extendability? | y/n | who | 28. June | who | 2. July | ||
FRAMES Extension Concept | y/n | Stef | 28. June | Rob | 2. July | ||
Loop Extension Concept | y/n | who | 28. June | who | 2. July | ||
OGC Extension Concept | y/n | who | 28. June | who | 2. July |
...
- Rename TimeSpace versions, leaving out the TimeSpace part of the name .
- Adding emtpy interfaces .
Adding empty interfaces would be:
...
And ILinkableComponent would be an empty interface provided for backward compatibility with OpenMI 1 and for ease of development. We have to decide if the advantages outweigh adding a number of empty interfaces. Maybe we can add them but put them in a "openmi1" extension (perhaps even marked as deprecated).
Adding empty interfaces has some unwanted side-effects:
...
(Jesper) I would recommend to keep the TimeSpace name there , not adding any empty interfaces. I would also prefer to remove the Base part of the name from the base interfaces, i.e. IBaseLinkableComponent to just ILinkableComponent .
Add property to indicate lengths of the dimensions to IValueSet
Meeting Decision: It was decided to go with the IBase... and ITimeSpace... interfaces names, and not have for example an empty ILinkableComponent interface. Although this requires more work on updating the documentation. Wether to use inheritance hierarchy or multi inheritance for defining the extension interfaces is still under discussion.
Add property to indicate lengths of the dimensions to IValueSet
(Rob) Not sure what the lengths of the dimensions would indicate and why you would have to specify (Rob) Not sure what the lengths of the dimensions would indicate and why you would have to specify them all the time?
(Gena) The lengths of the dimensions
...
is required in order to implement code which knows only about IValueSet, otherwise IValueSet is useless without information about specialized implementation. Once we have instance of the IValueSet - we can call GetValues / SetValues without need to know about specific implementation. In the current version you are forced to extract number of times and number of elements from the specialized version, and only after that it is possible to call GetValue / SetValue.
Wiki Markup
| Code Block |
|---|
double[][][] values |
...
(Rob) I have added the following methods to the IBaseValueSet (Java) :
| Code Block |
|---|
/**
* Returns the number of possible indexes (dimensions) for the value set.
*
* @return number of indexes, zero based
*/
public int getNumberOfIndexes();
/**
* Returns the length (max index count) of the dimension specified by the
* given indexes.
*
* @param indexes of the dimension to get the length of
* @return length of the specified dimension
*/
public int getIndexCount(int[] indexes);
|
Add ValueType to IValueSet
Meeting Decision: All agreed to adding this to the IValueSet. C# code will be updated following what was already added to the Java code.
Add ValueType to IValueSet
(Rob) Would be a good thing(Rob) Would be a good thing, I agree (has been discussed before).
...
(Rob) Agree, let's add only ValueType (not IValueDefinition) to avoid returning to old discussions 
(Jesper) But then you do not know the size of it either, hence you would need the spatial definition and time definition as well? I think a better solution would to include the IExchangeItem within the value set, if this kind of information is required.
Meeting Decision: All agreed to the solution of adding only the ValueType to the IValueSet. Adding a reference to the IExchangeItem would force the developer to always create copies of the IExchangeItem since it is only a reference that can be updated.
Get/set multiple values from IValueSet
Wiki Markup
(Rob) Perhaps we could leave this to specialised high performance versions of IValueSet?
(Gena) The use of interfaces without methods / properties is a very bad code smell AFAIK. If we introduce IValueSet and define it as a generic way to access values - it should provide way to do so.
...
(Jesper) Alternatively these can be implemented once and for all as C# extensions, which will be able to utilize high performance implementations, but does not require to be a part of the public interface.
Meeting Decision: All agreed to leave this out of the IValueSet for OpenMI 2.
IExchangeItem event
(Gena) What is our goal with ItemChanged event in IExchangeItem? Do we want to get this event fired only when values of the exchange item are changed? If yes - then let's rename it to ValuesChanged and add indices to it (indicating which values were changed). That should make it much more useful.
...
(Rob) I have updated the method name in IBaseExchangeItem as follows :
| Code Block |
|---|
/**
* Returns an Observable to be used to receive notifications from the
* exchange item about content changes. This notification is sent when
* the exchange item values have been updated. It is the responsibility
* of the observer to figure out which actual values have changed and
* how to act on these changes.
*
* The argument passed in the Observer update call must be an instance of
* the ExchangeItemValuesUpdatedEventArgs class.
*
* @return Observable for receiving exchange item change notifications
*/
*/
public Observable getValuesUpdatedObservable();
public Observable getValuesUpdatedObservable();
|
Also renamed the event args class to: ExchangeItemValuesUpdatedEventArgs .
Meeting Decision: All agreed to this change, the C# code will be updated accordingly. It was noted that some additional events / notifications should be added to the ITimeSpaceExchangeItem for changes to the time set and element setAlso renamed the event args class to: ExchangeItemValuesUpdatedEventArgs.
Namespaces for interfaces
...
(Jesper) I would then probably make a spatial/geometry namespace or similar, that holds the ISpatialAxis, IElementSet, and the future ISpatialLine or whatever types of geometries that are required to be supported. Because most likely the TimeSpace version is not the only type of component that requires a spatial definitionrequires a spatial definition.
Meeting Decision: Agreed to create the timespace namespace and put relevant interfaces there. Base interfaces are to be put in the root (standard) namespace.
Other issues
- (Peter) What happens if MyDictionaryComponent gets linked to MyLinkableComponent? Does one class have to derive from both extensions? (MyLinkableDictionaryComponent : IBaseLinkableComponent, IDictionaryComponent, ExtensionTimeSpace) Is there more than we can properly think through in three weeks?
...
(Jesper) When it implements the IBaseLinkableComponent, then it is OpenMI 2.0 compliant. The rest is in principle up to adaptors. We could consider to require that components also specify which extensions it supports, i.e. a 2.0 TimeSpace component is base compliant and time-space-extension compliant.
Meeting Decision: Adrian pointed out that with this support for extensions we should be more clear about what compliancy means. Even with OpenMI 1.4 it is not clear to a user what he can expect when a model is OpenMI compliant. We agreed to work on a better definition of OpenMI compliancy and add it to the documentation.