[saga-rg] SAGA conference call

Andre Merzky andre at merzky.net
Fri Apr 21 02:32:49 CDT 2006


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





More information about the saga-rg mailing list