Quoting [Hidemoto Nakada] (Apr 21 2006):
All,
sorry for not being able to attend the call. here are some comment on GridRPC.
No problem - we realise it was on short notice.
Andre Merzky wrote:
- SAGA and GridRPC: - some progress on mailing list - two potential point of conflict with current GridRPC API - config file exposes implementation on API level what is the canonical way in SAGA to path optional configuration information to a binary?
The spec is silent about configuration :-(. The SAGA approach however would be to move that responsibility away from end user level, to the administrator level. For example, environment specific configurations should be performed by the administrator who installes SAGA, not by the programmer who uses SAGA.
a specific-named file in the current working directory might work as well.
That is probably convenient and useful - but should, IMHO, the last resort. A search for configuration in some other predefined places, such as $INSTALL_ROOT/share/saga.ini /etc/saga.ini ~/.saga.ini `pwd`/saga.ini (that at last) would, as described above, allow the administrator to configure SAGA We also have to keep in mind that we might need configuration for not only RPC, but for other parts of SAGA as well. Multiple config files are probably not a good option, or at least not in multiple formats. So just including the RPC config handling as is is, unfortunately, not advisable IMHO.
- varargs are used, which we did not consider yet (SIDL?)
To have single argument array might be the easiest solution.
Right, but you loose type conversion that way. I originally thought you use an array of strings - and only realised by looking at the implementations that varargs are used. The good thing about that is that it looks VERY simple from end user side. At least for C programmers, its also very familiar. For Java it might be impossible. So, one approach would be to define a single arg array, as you propose, in the spec, but allow the language bindings to implement that with varargs. Does that make sense?
- these issues should be addressed at GGF17 - apart from that, a RPC package (outside strawman) should be feasable between GGF17 and GGF18 - TODO ANDRE: create CVS dir, set up package and issue list - note: RPC sata handles not yet considered
what is 'sata' handle?
Oops, sorry - 'data handles'. That refers to the remote data handles you folx consider as an extension to the first GridRPC spec.
- note: relation to web services need clarification (there are SAGA use cases for that)
-hidemoto
Thanks for your feedback, Andre. -- "So much time, so little to do..." -- Garfield