[gridrpc-wg] Final call: GridRPC API for inclusion in SAGA 1.0

[Thilo Kielmann]

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/