...
1. Progress towards OpenMI 2 Beta release
1.1. Source code updates
The trunk has been tagged as
| Code Block |
|---|
/svnroot/openmi/tags/OpenMI-2.0.0-20100618-BeforeExtendable |
, before any of the extendable changes have been applied.
The OpenMI-2.0.0-extendable branch has been merged into the trunk. This means that the OpenMI-2.0.0-extendable branch should no longer be used (and eventually deleted).
1.2. Documentation updates
...
(Rob) I prefer the second option. However besides stating when something is compliant, I think we should also make it more clear what this means in practice for the average modeler / user.
(Jesper) I would also vote for the second option. Though maybe rephrasing:
2. An OpenMI compliant component can also comply to one ore more extensions, by implementing the IBaseLinkableComponent interface and the extension interfaces which it wishes to comply to, according to the specifications provided as comments in the OpenMI.Standard2 source code.
2.1.1. Slightly changed from 1.4 compliancy
...
(Rob) Still considering the two approaches: using a hierarchy (i.e. ITimeSpaceLinkableComponent extends IBaseLinkableComponent, MyComponent implements ITimeSpaceLinkableComponent) or composition (i.e. MyComponent implements ILinkableComponent, ILinkableComponentTimeSpaceExtension). Should consider the effect when adding a linkable component interface for the loop method(s) or for the FRAMES dictionary support. Also see how OGC spatial element sets can be added as an extension and how this effects the interfaces.
(Jesper) I have added a third alternative, which is somewhat in between. The more I look at it, the more I prefer alternative 2.
Alternative 1 (interface hierarchy):
...
| Code Block |
|---|
ILinkableComponent { base methods };
ILinkableComponentTimeSpaceExtension { time-space methods };
ILinkableComponentParallelExtension { loop methods };
ILinkableComponentDictionaryExtension { dictionary methods };
MyParallelTimeSpaceComponent implements ILinkableComponent, ILinkableComponentTimeSpaceExtension, ILinkableComponentParallelExtension {};
MyParallelDictionaryComponent implements ILinkableComponent, ILinkableComponentDictionaryExtension, ILinkableComponentParallelExtension {};
|
Alternative 3 (in between):
| Code Block |
|---|
IBaseLinkableComponent { base methods };
ITimeSpaceLinkableComponent extends IBaseLinkableComponent { time-space methods };
IParallelLinkableComponent extends IBaseLinkableComponent { loop methods };
IDictionaryLinkableComponent extends IBaseLinkableComponent { dictionary methods };
MyParallelTimeSpaceComponent implements ITimeSpaceLinkableComponent, IParallelLinkableComponent {};
MyParallelTimeSpaceComponent implements IDictionaryLinkableComponent, IParallelLinkableComponent {};
|
3. New discussion topics
3.1. How to package and distribute extensions
(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.