...
All proposed changes resulting from the previous meeting have been realized.
2.2 Backbone
Gena update updated the backbone according to the latest version of the Standard after meeting 23.
Small modifications by Stef and Adrian afterwards.
Note: the documentation is not up to date at all.
Actually: the documentation of the Standard is the most important one. We could already start to work on this documentation for the more static items, like the ValueDefinition, ElementSet, etc.
...
| Code Block | ||||
|---|---|---|---|---|
| ||||
IInputItem consumerThatIsAsking;
consumerThatIsAsking.TimeSet.Times[0] = requiredTime;
while (!providingOutputItem.IsAvailable(consumerThatIsAsking)) {
providingOutputItem.Component.Update();
}
values = providingOutputItem.Values;
|
Note (Gena): We may want te consider looking again at the IsAvailable method, and separate it into 2 different indicators, e.g.
- IsValid on the exchange item
- canProvide or something like that on the decorator.
Note (Stef) On the other hand, this would be confusing for the consuming input item (is it accessing an output item or a decorator?).
For now, we will
...
various implementation examples
...
using IsAvailable. We will then check if IsAvailable suffices.
Related issue: The while(!Available){Update} code above is actually representing the original 1.4 GetValues() call. So it might be wise, to put emphasis again on the still working 'pull approach', to introduce a getValues() call, e.g.:
...
- Are we happy with IOutputItem.IsAvailable() and with ILinkableComponent.Validate(), or do we need additional methods on LinkableComponent and/or ExchangeItem to check validity.
We Conclusion after a first discussion: we are happy. The only small change that has been proposed and has been agreed on is:
The return value will be an array of strings, to let the component compose a multi line message.
Some second thoughts came up when Gena emphasized that by this mechanism the outer world can not determine which input/output exchange items are in erroneous state.
To be rediscussed at this meeting (Thursday morning).
- Should we introduce a boolean argument that indicates whether the component should run in a pull mode (like in OpenMI 1.4) or in loop mode?
- Discuss component operation mode here comment from Peter Gijsbers need to be discussed
Discussion/Conclusion: We decided to let the LinkableComponent have a propery: CascadingUpdateCallsDisabled.
The default is false, indicating that the component is running in Pull Driven mode (there will be a cascade of update() calls. This Pull Driven mode has to be supported by every component.
If set to true, the component is expected to run Update()-step by Update-Step(), controlled by some outer world (which may be another component). If the component does not support this Update() by Update() way of running, it will throw an Exception when CascadingUpdateCallsDisabled= true is called.
In the GUI, the user hat to tell which component is at the end of the chain. This controlling component will be triggered first.
- The Timezone issue has been re-adressed.
Discussion/Conclusion led to the following decisions
: - Daylight Saving Time jumps in time series are not allowed
- The TimeSet will contain a property that expresses its offset from UTC, expressed in hours (OffsetFromUtcInHours). The Gui will check these offsets, and if they are different, it will ask the user to put a decorator in between.
Note: in future and/or more platform specific versions of the standard we may reconsider introducing the timezone info again.
...
- IArgument needs a mechanism for identifying the type of argument e.g. File, Path, int double etc Very usful for providing customised GUI functionality
Various solutions were proposed (see below). Disadvantage of having an enumeration in the Standard is that it can not be extended easily. An object type definition would be more specific.
Rob K. concludes that Alterra's approach works quite well for what we want. The approach is based on recognized strings in the key of the Argument.
Action: Rob K. will provide an example.
Done June 10: Please see the IArgumentV2.java class file that I have attached to these meeting notes. This interface documents all the extensions we made to standard OpenMI 1.2 IArgument interface to make it more usable for our (GUI related) purposes (some time ago). The comments in the source file should provide all the explanation needed
After studying that, we will discussed what to do
We have studied the example and various propositions, and choose for to the following solution (to be documented yet) .
Adrian's proposal:
| Code Block | ||||
|---|---|---|---|---|
| ||||
namespace OpenMI.Standard
{
public enum EArgType
{
String = 0, // default
Bool,
Int,
Double,
Path, // presummed to exist and accessable
FilePath, // presummed to exist and accessable
PathNew,
FilePathNew,
XML, // Rob: can be used together with a schema for complex argument data
MIME, // Rob: might be useful to pass in images, or text documents, etc.
}
/// <summary>
/// The IArgument interface defines a key - value pair. If the property ReadOnly is
/// false the value is editable otherwise it is read-only.
/// </summary>
public interface IArgument : IDescribable
{
/// <summary>
/// Type that string value represents and can be converted to
/// </summary>
EArgType ValueType { get; }
/// <summary>
/// The key (string) in key-value pair.
/// </summary>
string Key {get;}
/// <summary>
/// <para>The value (double) in key-value pair.</para>
///
/// <para>If the ReadOnly property is true and the property is attempted to be changed
/// from outside an exception must be thrown.</para>
/// </summary>
string Value { get; set; }
/// <summary>
/// Defines whether the Values property may be edited from outside.
/// </summary>
bool ReadOnly {get;}
}
}
|
...
- Suggestion by Gena on pull / loop approach
Discussion/Conclusion: A good idea to introduce the GetValues, to recognize the pull approach. However, instead of on the LinkableComponent, for now it has been put on the output item (see above).
...