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

[Andre Merzky]

Hi, 

Quoting [Thilo Kielmann] (Aug 10 2006):
> 
> 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? ;-)

Fair enough :-P


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

Well, that was the reason why rpc was not included in the
spec, yet.  If I'd had the ability to fix the stuff myself
I might have done it already, but I'm afraid I don't...


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

hehe, worked...


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

*nod*


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

No, not a problem, but a contradiction:

  "All elements but the scheme can be empty ..."
  "An empty URL means ..."

I would prefer to allow the URL to be totally empty.


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

It is implicitely expressed in SIDL already.  We might want
to add a verbose note though


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

Hmm, someone needs to go through the RPC spec and check what
errors are defined there, and map them to SAGA exceptions.
Volonteers? ;-)


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

Ok, fine with me.


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

hehe - ok, that makes things much easier.


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

Ok.  

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

No, I don't mean for async operations.  For example (C++):

{
  {
    saga::rpc rpc (url);
    rpc.call ();
    // BTW: ar void calls allowed?  i.e. can the param list
    // be empty as default?
  }

  // the rpc handle is destroyed here.
}


  So, the handle is destroyed - the programmer can, however,
  not be sure that remote resources are really freed - thats
  up to the implementation.  In provious discussion we came
  hence up with:

{
  {
    saga::rpc rpc (url);
    rpc.call ();
    // BTW: ar void calls allowed?  i.e. can the param list
    // be empty as default?

    rpc.destroy (-1);
    // remote resources are now freed

    rpc.call (); 
    // this call woudl throw an IncorrectState exception
  }

  // the rpc handle is destroyed here.
}

That cancel() allows to explicitely free remote resources,
and can, if necessary, block until that is ensured.  To have
that ability was actually a request by the RPC folx IIRC,
and we added it to several places in the SAGA spec (streams,
name space entries).  So I guess we should stick to it here?

Cheers, Andre.

> Thilo

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