[SAGA-RG] FW: ISN spec

[antony.wilson at stfc.ac.uk]

Hi Andre

More changes made

> 
> Hi Antony,
> 
> thanks to you, too, for the detailed replies! :-)  Some comments
> below....
> 
> 
> >>  - the classes do not inherit the saga::async interface, and thus
> will
> >> not have asynchronous operations.  Is that on purpose, or an
> >> oversight?
> >
> > Again this is to remain consistent with the SD spec
> 
> Again, that point makes certainly sense, but may again point to an
> oversight in the SD spec.  What is the rationale behind that decision?
>  All other packages support remote operations, as it basically does
> not carry any ballast on implementation side (once you have
> implemented a way to do remote ops, its relatively easy to apply that
> to all calls), and async operations seem very useful in distributed
> applications?

I believe a the time it was considered that call to sd would be relatively fast. 
Do you have a use case for making use of sd in an asynchronous manner?

> 
> 
> >>  - You do not have TimeOut, PermissionDenied,
> >> Authorization/Authentication etc exceptions.  I am unclear about the
> >> underlying protocol (and the API should not care), but are you sure
> >> those error modes do not (ever) apply to the calls?
> >>
> >>
> >>  - some calls have no exceptions whatsoever - are you sure they will
> >> *always* succeed? :-)
> >
> > Added to constructor
> >
> > get_data and list_related_entity_names
> > the data has already been loaded and parsed as a result of the
> constructor so will always succeed
> 
> Well, you assume that your implementation fetches all data on the
> c'tor, and does no extra queries later on.  But is that semantically
> prescribed by the API?  I can't see that in the current spec - I think
> a stateless client could be implemented according to that API spec.
> 
> IFF you prescribe such a cache (and thus client state), what is it's
> scope, and its lifetime? Infinite may be a valid lifetime value I
> guess, but I doubt one would cache related entities of related
> entities?
> 


By the nature of our implementation these make no sense but I accept that 
They may be relevant to other implementations

get_data() - added NoSucsess and Timeout exceptions
list_related_entity_names() - added NoSucsess and Timeout exceptions


> While checking again: get_related_entities(): it is not well specified
> when BadParameter is thrown.   The filter being ill-formed is obvious
> - but what happens on an related_name parameter which does not exist?
> Would a DoesNotExist exception possibly be a better match?
> 

get_related_entities(related_name, filter) -added DoesNotExist exception and a note

> 
> > exceptions Timeout to get_related_entities
> > these calls should return objects that you are authorized to see
> 
> Are no race conditions possible between list_related_entity_names and
> get_related_entities (name)?  Like, could an entry name returned by
> the first call disappear in the backend database before the second
> call gets called?

No, the entity names returned from list_related_entity_names are those defined in the glue schema, if they change then we need a new model

> 
> > 
> Yes, this makes sense.
> 
> 
> Best, Andre.
-- 
Scanned by iCritical.