Dear Andre, Yusuke, Hidemoto, dear "groups", now that the SAGA CVS has lost its (recent) memory, let's sort out things via email. (Actually, when I did 'cvs update' yesterday, I wanted to fix this stuff directly in the repository :-( After some thinking, I believe that whatever we write into the RPC section of SAGA, it has to be implementable over the GridRPC spec, as of GFD.52. Otherwise, it wouldn't be "GridRPC" but merely SAGA RPC. While this might have benefits, I believe, for the sake of usefulness, we should stick to GFD.52. (Otherwise we might rule out some popular RPC implementations like Netsolve.) My following comments have to be seen in this light.
In the constructor, the remote procedure to be invoked is specified by a URL, whith the syntax:
gridrpc://server.net:1234/my_function
with the elements responding to:
gridrpc - scheme - identifying a grid rpc operation server.net - server - server host serving the rpc call 1234 - port - contact point for the server my_function - name - name of the remote method to invoke
All elements but the scheme can be empty, which allows the implementation to fall back to some default remote method to invoke (minimal URL: gridrpc:///).
The description of the constructor says that the URL can be NULL, in some languages that will mean 'empty' (e.g. if they have no default args). That would mean that scheme can be empty, too.
I think we can allow completely empty URL's, too. (There is an obvious default value for the implementation to fill in, right? ;-)
This argument handling scheme allows efficient (zero-copy) passing of parameters. For 'Out' parameters with a size value of 0, the implementation is required to allocate the data structure and to overwrite the size and buffer fields for the parameter.
It is the responsibility of the application programmer to free this memory I assume? The the language bindings MUST prescribe how that memory is allocated, to allow the application to choose the appropriate de-allocation method. Alternatively we would need an 'dealloc' method, which would then require the implementation to alloc and de-alloc the params (and to keep track of the blocks).
we can add this to the text.
- The RPC spec is silent about 'when' the connection to the remote server is made, on creation of the handle, or on call(). We decided in other parts of the spec that, for example, the constructor opens a file, or remote connection. I propose to prescribe the same for RPC. Does that make sense? Do we need to loosen the semantics elsewhere in the spec? (IMHO not).
To my personal taste, I would prefer having the accessability check in the constructor, enforced. However, this would contradict GFD.52 (see above). So we should have "all useful" exceptions (see below) both for the constructor and the "call" method.
- constructor Purpose: inits a remote function handle Format: CONSTRUCTOR (in session session, in string funcname) Inputs: session: saga session to use funcname: name of remote method to initialize Outputs: -
I suggest the following mappings of GridRPC errors to SAGA exceptions: GRPC_SERVER_NOT_FOUND IncorrectURL GRPC_FUNCTION_NOT_FOUND IncorrectURL GRPC_RPC_REFUSED AuthorizationFailed looks like the closest match GRPC_OTHER_ERROR_CODE NoSuccess default GRPC_NO_ERROR and GRPC_NOT_INITIALIZED are not applicable.
- call Purpose: call the remote procedure Format: call (inout array<parameter> param); Inputs: - In/Out: param: argument/result values for call Outputs: - Throws: NoSuccess: remote operation failed
same as constructor
- should we add a 'cancel(in float timeout)'? Explicit resource dealloction was an issue in our discussion at GGF, and we agreed on cancel - is that not needed anymore?
I gave it a thorough (I hope ;-) read and came to the following conclusion: We have to rely on GFD.52, this means here on grpc_cancel(). grpc_cancel is meant to cancel an asynchronous rpc call. The description in GFD.52 does NOT mention any remote resource de-allocation. This means, prescribing in SAGA some form of remote resource de-allocation would deviate from GridRPC and would likely not be implementable. This means, all we can do is cancel the SAGA task (possibly with timeout -1). And, if I understand SAGA's task cancel method correctly, it is supposed (or at least allowed) to "clean up resources", which I would translate to calling grpc_cancel underneath. Summary: no explicit cancel method for SAGA's RPC package Thilo -- Thilo Kielmann http://www.cs.vu.nl/~kielmann/