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

[Thilo Kielmann]

Andre,

thanks for your comments. More or less, we agree on this.
more comments inlined (why should YOU not be forced to search for them? ;-)

BTW: most deficiencies you rightly spotted are parts of the text that we 
simply inherited from your presious version. Feel free to fix ;-)

> I felt free to change some part to adapt it to the spec look
> and feel (example coding conventions, intendation etc.).
> I'll convert that version to tex now, and add it to the
> CVS.  Hope thats ok with you.

Actually, I was hoping for this.

> There is one conflict: I hope that we can get the SAGA CORE
> spec into final mailing list call on Monday.  So I suggest
> to NOT move that timeline backwards, but to include rpc
> already - if either of the final calls meets negative
> comments we remove it - does that make sense?

There is no conflict. Just, SAGA folks have a few days more to object...

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

what does this mean? is this a problem?

> Not that I disagree, but it should be noted that even for
> RPC calls which require input parameters only, the params
> must be passed by reference.  That implies, in some
> languages, to track the param memory for async invokations,
> where that is not the case for async invokations of other
> languages which don't have no output parameters.  It can;t
> be helped I guess, and should not be an issue really.

fine, can you say this in SIDL, too? ;-)

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

yep, we can add a sentence pointing out that this needs to be addressed in the
language bindings.

> 
> I assume a number of other exceptions would apply as well,
> such as 
> 
>   AuthenticationFailed
>   AuthorizationFailed
>   PermissionDenied
>   DoesNotExist (server contacted, but no such call available)
>   IncorrectURL
> 
> Well, and some more I guess.  Question is: NoSuccess is
> actually reserved as last resort, if no other exception
> really applies (its the least specific exception, please
> have a look at the 'error handling' section in the spec).
> So, is NoSuccess really needed here, and in what conditions?

this deficiency is nicely inherited from your old text. Can you please 
embellish this? (nobody really insists on 'NoSuccess'

> >       Notes:   - see [1] for details
> >                - by passing an array of variable size, 
> >                  different numbers of parameters can be 
> >                  handled. No special variable argument
> >                  list handling is required.
> 
> We discussed varargs at one of the last GGF, and came to the
> conclusion that language bindings COULD allow varargs.  That
> does not make sense with the proposed scheme, in particular
> in respect to the memory allocation policy described.  So, I
> guess we abstain from varargs in the language bindings then?

by this definition, we can avoid varargs. so let's do that?

> Other open questions we had from former RPC discussions,
> and which should be addressed in this spec, are:
> 
>   - GridRPC takes a config file name on initialization.
>     That config file needs to be user specific IIUC, and
>     there was some discussion, but no conclusion about that.
>     So, what is the appraoch on that?  Is that spec
>     implementable on top of GridRPC, and how?  If that is an
>     issue still: our decision was to include the config file
>     URL as (optional) parameter to the CONSTRUCTOR.  Does
>     that make sense?

Hidemoto, Yusuke, and I agreed to leave the config file out of the API.
We think this is better. (Hidemoto was even harsher with himself who once
put the config file into the gridrpc spec ;-)

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

I am afraid, doing so would impose restrictions on the underlying gridrpc
implementations. some of them might not meet them, but would still be useful
if SAGA could access them.

What you really would have in mind is a test "can execute" of the procedure?
I am not sure if the constructor could aalready give a comprehensive answer???

Hidemot, Yusuke, any ideas ???

> 
>   - Ninf-G allows to bind a handle to multiple calls.  I
>     assume that this is hidden in the implementation for
>     now, and has no explicit reflection in the API?  I think
>     that is what we decided on anyway...

looks like

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

hmm, wouldn't the cancel() belong to the task ???


Thilo
-- 
Thilo Kielmann                                 http://www.cs.vu.nl/~kielmann/