Yusuke, Quoting [Yusuke Tanimura] (Aug 10 2006):
Hi,
- 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???
Hidemoto, Yusuke, any ideas ???
In case of the GridRPC, when the connection to the remote server is made is free for each implementation. In the constructor, the server will be certainly assigned for the RPC. The connection for data transfer may be established in the constructor (Ninf-G) or may be done in rpc.call (GridSolve).
Right, that is what I remember from last GGF as well. That means effectively that the call() method must be able to throw all exceptions we have on the constructor of the handle. No, the question is how do we handle that for other SAGA packages, e.g. for files? Here the constructor implies an open(), and could return DoesNotExist. If SAGA would allow to delay the opening of the file, it would be possible to save a round trip time, and to optimize the implementation - but the drawback is that on _any_ other call (read(), write() etc) we could meet a DoesNotExist exception. I guess we don't want that, and should limit that semantics to RPC. However, we then end up with an inconsistency in the spec (file constructor behaves differently than rpc constructor), which we need to document explictely (at least). Does that make sense? -- "So much time, so little to do..." -- Garfield