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/