See also: OATC Wiki Home

Date: 27. Januar 2011
Time: 10:00 - 11:00 CET
Venue: Skype Conference Call
Topic: OATC SDK

Table of contents

Participants

Adrian Harper, MWH Soft Ltd (adrian.harper@mwhsoft.com)
Stef Hummel, Deltares (stef.hummel@deltares.nl)
Standa Vanecek, DHI (s.vanecek@dhi.cz)
Peter Schade, Bundesanstalt fuer Wasserbau (peter.schade(at)baw.de)
Rob Knapen, Alterra, Wageningen UR (Rob.Knapen@wur.nl)
Jesper Grooss, DHI (jgr@dhigroup.com)
Unknown User (don), Deltares (gennadii.donchyts@deltares.nl)

Apologies:

1. Outstanding issues from previous meetings

Last meeting conclusion (January 14th): see notes in Chapter 4 below

The 32/64 bit conclusions

Stef posted an additional note: Build the main application (i.e.Oatc.OpenMI.Gui.ConfigurationEditor.exe) specifically for the x86 platform. The executable will then treat the dll's which have been built with the "Any CPU" option as 32-bit dll's.
So the Oatc GUI and the Pipistrelle GUI should be delivered in a 64-bit and a 32-bit version.

This way the the .Net level will be covered, but of course on a native level there might still be the problem that a 32-bit DLL can not be loaded when running 32-bit. This will lead to a run time exception.

However, 64-processes can be called from the 32-bit application (e.g. when calling a perl script).

In the compliancy file a model provider should be able to specify how the assembly/assemblies was/were built: 32-bit, 64-bit, and/or Any-CPU.

The FluidEarth SDK will support running an engine remote (in the set up the user has to specify the ip-adresses). It is based on TCP/IP (SOAP might be added later on, to cross fire walls).

2. Signing dll/jar

Rob, can you fill in here? -> See text below, question on how to proceed remains.

Text from last meeting minutes:

There was an initial attempt to retrieve the private key used for signing the C# DLL but this did not appear to be possible (at least not in a trivial way). Since signing the DLL with a new key would mean having a new version of the DLL it was decided to sign the Java jar with a different key. Both key pairs will be kept by the chairman of the OATC.

Signing of the Java JAR file is possible using the keytool and jarsigner utilities from the JDK. A keystore (password-protected database) has to be created that holds the generated private key(s and certificates). Info from the keystore can than be used to sign the JAR and to export the public key that has to be published. For verification a user has to import the public key with the keytool and can then use jarsigner to verify the JAR. A certificate from a certification authority can be used for improved security.

Since the used .Net Strong Name Key was and is in a (public readable) SVN I think it should be considered "compromised" and not really suitable for authentication anymore. We probably have to discuss the whole signing issue and its purpose again at the next meeting before taking further steps.

From version 2.1 on, we will work according as proposed above.

3. Open SDK issues

From SourceForge Tracker - Bugs

  • ElementMapper bug - the usage of epsilon. Jesper: There are several issues there, so the entire set of XY geometry classes needs a revisit.
  • The Configuration editor does not set currentDir to the loc.
  • Hashcode not equal.
  • GUI 1.4.1 beta issues - also relevant for the current 1.4 GUI.
  • Unit conversion does not handle missing values

From SourceForge Tracker - Feature requests

  • Connection dialog should call its own UpdateControl()
  • Performance hit due to events

Conclusions/Status:

  • ElementMapper: Has to be revisited indeed. We do need the mappers in 2.0, either with documention on there problems, or in a fixed way, or by using other tools. At HR people are working on the mapping issue. Could also be something for a student. Conclusion: We will copy the issue to the FluidEarth issue tracker (action: Jesper), and see to which actions/solutions it will lead in the Fluid Earth community.
  • currentDir in Configuration Editor: (action) Adrian will have a look at it.
  • Hashcode not equal: (action) Stef/Jasper
  • GUI 1.4.1 beta issues: Deprecated
  • handle missing values in unit conversion: A unit conversion tool has to be developed anyway. And indeed it should handle the missing value. During the discussion we found that we miss the MissingDataValue on the IValueSet (action: Stef).

The various issues on the tracker we be addressed at next meeting (see below)

From: Trac Wiki

4. Notes on IValueSet/ITimeSpaceValueSet discussion of Thu Jan 13th.

Purpose of the discussion is to clearify the distinction between IValueSet and ITimeSpaceValueSet

Summary of the discussion and findings:

  • The IValueSet is a general n-dimensional array of values
  • The first three methods of the ITimeSpaceValueSet (Values2D, GetValue, and SetValue) actually just narrow the value set down a two-dimensional array of values
  • The time and space axes come in with the other methods (GetTimeSeriesValuesForElement, SetTimeSeriesValuesForElement, GetElementValuesForTime, and SetElementValuesForTime)
  • In earlier versions, there was a choice whether the first index represented time or space. The latter then could be used for efficient access and storage of time series. However, this choice has been removed, and therefor now the first index always represent the time axis.
  • If a third axis comes in, e.g. because of an array of quantities, this axis is represented by defining the ValueType as double[]. However, this means that the number of quantities in the array can not be specified. This could be handled by introducing in an extension some 'well known types', like a Vector, a Tuple, etc., and specify these as ValueType.

Adrian mentions he wanted to address the subject because he is implementing an SDK from scratch for Fluid Earth. This is not because of the fact that he does not value the Oatc's SDK, but because of the fact that he wants a clear understanding of 2.0 and its implementation.
The other meeting participants think that it is good to have such a clear new SDK. In the end we will most probably then have an SDK with 'the best of both worlds' (FluidEarth and Oatc).

5. Next Skype meetings

  • Regular meeting, focus on issues in tracker, Thursday, 3.2. at 9:30 CET (8:30 UTC)
  • No labels

Disclaimer