Hi all, I got following forward from Rosa Badia, as an answer to the saga-rpc proposal. Pieter makes some interesting points... Cheers, Andre. ----- Forwarded message from pbellens@ac.upc.edu -----

Date: Mon, 20 Mar 2006 10:47:18 +0100 From: pbellens@ac.upc.edu To: rosa.m.badia@bsc.es Subject: Re: [Fwd: [saga-rg] Re: saga update... (iii)]

#include <saga.hpp>

string func_name = "pi/pi_trial"; string config_file = "file:///client.conf";

int main (int argc, char *argv[]) { .. std::vector <long> count; saga::task_container tc;

for ( int i = 0; i < n; i++ ) { // create rpc handle saga::rpc handle (hosts[i], func_name, config_file);

--> In Ninf-G, one creates an object handle that specifies a host and a module name, where a module can contain anywhere from 1 to many functions. That comes in really handy, since you can access a lot of functions with a single object handle creation call. For the case above, you would need 100 handles to access 100 functions. Unless you start wrapping those functions, but that s a lot of work, and pretty ugly. The object handle/Ninf-G case is not part of the official GRPC standard though, whereas the SAGA handle initialization does follow the standard. Personally, i prefer Ninf-G's approach here.

// perform async call saga::task t = handle.call <saga::async> (i, times, &count[i]);

--> Because the handles are treated different, the GRP call itself differs as well. I don t see how they pass a callback function, though. In Ninf-G, each asynchronous GRP call contains a callback function as an argument.

// wait tasks (for ever, for all) tc.wait (-1.0, saga::task::All);

--> Here you wait on a function container, in Ninf-G one waits for individual function calls. Although you can wait for several functions, by using logical AND or OR functionality. This is an interesting feature of SAGA, although we don t need it.

.. return (0); } ----------------------------------------------------------- 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.

--> This makes sense. However, it would make sense to gather all configuration files into one single file, and use that single file at runtime initialization time, just as Ninf-G does.

kind regards,

pieter

-- "So much time, so little to do..." -- Garfield