You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »

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)
~jgr@dhigroup.com, DHI (jgr@dhigroup.com)
~don, Deltares (gennadii.donchyts@deltares.nl)

Apologies:

1. Outstanding issues from previous meetings

  • Last meeting conclusion (January 14th).
  • 32/64 bit conclusions

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.

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

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 - suggestion: Thursday, 3.2. at 10:00 CET (9:00 UTC)
  • No labels

Disclaimer