...
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 Unknown User (don), Deltares (gennadii.donchyts@deltares.nl)
...
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.
...
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
...
- 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.
...
5. Next Skype meetings
- Regular meeting - suggestion: , focus on issues in tracker, Thursday, 3.2. at 109:00 30 CET (98:00 30 UTC)