Quoting [Hidemoto Nakada] (Mar 23 2006):
Andre,
I realised that I forgot the config_file argument to the handle creation in the last (synchroneous) example - it should look like above. That actually _is_ a difference to GridRPC: as the session in SAGA is not RPC specific, it makes no sense to have a RPC specific config file for a session. Hence, the config file would need to be attached to the handle creation.
Please note that the GridRPC config file is not per session, but per whole client program.
the config file should be passed to the saga::rpc class, like
saga::rpc.init(config_file);
where 'init' is a class method of the rpc class.
Hi Hidemote, I'd like to understand the purpose of the config file better, so I have a couple of questions. I found the config-file section in the Ninf-G user manual. What is the general idea of the config file? To me it sounds like it configures the (client side) backend, not the API - would that not better be hidden in some ~/.ninfgrc or so? Are there many values which are intended to change from one application run to the next? The GridSolve user guide is silent about the config file structure - is it the same as in Ninf-G? If not, how does GridSolve handle the client side configuration?
PS.: as a side note, we do have the above form of RPC included in our saga reference implementation. However, it does not yet forward the calls to a NinfG or GridSolve adaptor. If anyone in this group has interest in connecting the reference implementation to a real GridRPC backend, please let us know :-)
We do have an java implementation for Ninf-G client. if your SAGA reference implementation is Globus-based and written in Java, it will be relatively easy to make it Ninf-G aware.
We write the reference implementation in C++ - so its even simplier I think :-) Cheers, Andre. -- "So much time, so little to do..." -- Garfield