[SAGA-RG] FW: ISN spec

[Andre Merzky]

Hi Antony,

thanks to you, too, for the detailed replies! :-)  Some comments below....

On Tue, Mar 15, 2011 at 5:50 PM,  <antony.wilson at stfc.ac.uk> wrote:
>
>>  - "No use-case has been identified for the operators >=, >, <=, < to
>> be applied to
>> strings. An Implementation wishing to support these comparison
>> operators on strings
>> MUST select a collation sequence. Alternatively, an implementation CAN
>> treat all
>> string comparisons as true, or reject them as invalid SQL."
>>
>>    IMHO, if the operators are defined, they should be evaluated, or an
>> error should be thrown.  I think it will 'surprise' users if the ops
>> are accepted, but not applied.
>
> I am inclined to agree but this is consistent with how the SD spec describes the treatment of strings

That makes sense, although one could argue that this points to a
problem/oversight in the SD spec.  But I have to admit that there are
some places in the SAGA core API were we don't cleanly handle similar
cases either.  So, I guess we have, at least for the time being, to
live with that.

Anyway, you may want to reconsider if fixing this would really be a
problem.  The mentioned cases in the core spec are planned to get
fixed at some point (FWIW).


>>  - 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?


>>  - 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?

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?


> 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?


>>  - you list two prototypes of 'get_related_entities' in the IDL
>> section, but only one set of details later on.  I guess you could use
>> a default parameter value for the filter in IDL to fix this?
>
> Added comment saying that the operation is overloaded, this is then consistent with the SD spec

Yes, this makes sense.


Best, Andre.


-- 
So much time, so little to do...
[Garfield]