[saga-rg] SAGA conference call

[Hidemoto Nakada]

Andre,

Andre Merzky wrote:
> 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.

I agree.
Do you think you will specify a specific configuration format
for SAGA API, like Java specifies properties file format?
In our experience, Java properties syntax is not
powerful enough for our config files.


>>>        - 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.

Note that in C varargs, type check will not happen in anytime.

Java, from JDK1.5, provides automatic conversion
from vararg type call to Object array and automatic
primitive type boxing. with them we can use effectively
same notation in Java.
in Java, you can type check at execution time.

> 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.
> 

-hidemoto