On Sun, Aug 13, 2006 at 01:30:06PM +0200, Andre Merzky wrote:
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.
We should explicitely describe that this is different to other constructors then.
Yes, no problem.
IncorrectURL is reserved fo non-parsable URLs, and URLs which cannot be handled because the scheme is unsupported.
Hmm, it that would be clear from the SAGA spec, I wold not have chosen "IncorrectURL" :-( So, what about the following mapping: GRPC_SERVER_NOT_FOUND DoesNotExist GRPC_FUNCTION_NOT_FOUND DoesNotExist 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.
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.
Hmm, I am somewhat confused now, as I thought (as said earlier) that the timeout on cancel was an GridRPC requirement. Well, nevermind then. Should we consider removing cancel/close timeouts from the spec altogether?
Unless I have overlooked something in GFD.52 (GridRPC), then the 'enforced' clean up can not be implemented there. Are there any other use cases for cancel/close timeouts?? I personally don't see much good in them: either the cancel manages to clean up, or it doesn't even after the timeout. This would onle be interesting if the same app would request more of the same remote resources. But still, either the remote resource manages to clean up, or sooner-or-later it will overflow... Thilo -- Thilo Kielmann http://www.cs.vu.nl/~kielmann/