Quoting [Steve Fisher] (Dec 18 2008):
In the attached version, I tried to address the things we agreed upon, and changed the service types/names table as proposed. Could you give it another pass, please? I left the Constructors untouched for now, until we agreed on something, ok?
Also, there is a question from me at the bottom of page 5:
"Note: Why not TimeOut, AuthorizationFailed, etc??"
For the discoverer constructor, I guess the Authentication exception can be thrown if you don't pass in a session or if you pass in what used to be a valid session that has since expired. How would you class that one?
A session cannot expire - its lifetime is defined by the lifetime of the objects which use that session. If a context (or credential) attached to that session expired, you can expect to see a lot of AuthenticationFailed exceptions, whenever that credential is being used.
Unfortunately quite a lot of the allocation of exceptions is implementation dependent. It would be better to be able to just throw a Security exception - but that is not an option as it is not in the core spec. If you need to get authenticated this could result in a timeout if contact with some remote server is required.
Well, than that is a TimeOut exception :-)) In general, it is of course difficult to map backend exceptions to SAGA exceptions in a meaningful way, but that cannot be avoided really, if the end user is to stay away from middleware exceptions.
In our current implementation, list-services does most of the work and so can throw timeouts and could throw security errors except that we happen to connect to a non-secured information service. However the subsequent calls (such as get_data) can throw the same exceptions as they could choose to go back to the information service to pick up information that was not originally needed when making the selection. If we don't allow the possibility to throw these exceptions the implementation is needlessly restricted. This is why I like the NoSuccess everywhere. In other words I would use NoSuccess for those conditions which are implementation dependent - which in this case is quite a lot.
Good point, so NoSuccess may make sense in all calls. I expected all implementations to simply fetch complete service descriptions, not only parts, but that may have been to limiting. But, is that really the way you expect implementations to work: to fetch some part of the service description, but, e.g., the name and URL just later on, on the get_attribute calls? That adds an awful latency overhead, which easily kills any bandwidth savings, as long as you stay below x.000 returned service descriptions - which is the dominating use case I dare to say. Requiring the implementation to fetch complete desciptions is a certain limitation, sure, but allows more tightly defined semantics for the application and end user... So, that is up to you (I do not know the implementations), but please consider the argument.
For example you have added DoesNotExist for the constructor - implying that the API would contact the underyling information service. However there is no reason why it should do so at this stage.
We have the same problem with the RPC package - there the Constructor has the following note: - according to the GridRPC specification, the constructor may or may not contact the RPC server; absence of an exception does not imply that following RPC calls will succeed, or that a remote function handle is in fact available. and the call() method has the following one: - according to the GridRPC specification, the RPC server might not be contacted before invoking call(). For this reason, all notes to the object constructor apply to the call() method as well. Also, call() has all exceptions of the Constructor, to allow for delayed throws. These notes are, as noted, a result of an underspecification of the GridRPC standard. I would really like to avoid to sprinkle such notes all over the place, as it makes a tight semantic definition of the API rather impossible. I think, if you have no really hard constraints from an underlying standard (as we had with RPC), or from a absolutely dominating implementation, it is not too much to ask from an implementation to ensure in the Constructor if the given (or chosen) URL actually points to a service which is alive and usable - what do you think? Otherwise, indeed, you need to repeat all exception on all calls (which makes catching and error recovery tedious for the application), or map them all to NoSuccess later on (which also gives the application no useful means to recover, e.g. an application does not get the info that a different URL or context may have helped).
Nothing is ever easy.
I am inclined to agree
:-)) Best, Andre.
Steve
-- Nothing is ever easy.