[SAGA-RG] FW: ISN spec

[Andre Merzky]

On Fri, Mar 18, 2011 at 4:02 PM,  <antony.wilson at stfc.ac.uk> wrote:
> Hi Andre
>
> More changes made


Thanks, appreciated!

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

Latency issues are a general concern in distributed applications, and
simply cannot be avoided.  Just as an example: a project we work with
does distributed runs over TeraGrid and DEISA.  No matter how the app
is configured, it needs to be able to cater for the cross atlantic
latencies.

Now, I agree that most use cases of SD do not cover high-frequent
queries - but IIUC, the ISN explicitely caters for browsing an
arbitrary information service interactively - that, IMHO, immediately
implies latency concerns.

Let me ask differently: what is the reason to *not* allow async ops?
In general, that does not change the service interface, but allows the
SAGA implementation to utilize threads for latency hiding.  What is
the downside?


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

Yes, that is the point - I understand that your implementation may
never throw those.  Thanks.


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

Ah, so an entry name being returned does not imply that data for that
entry exist in the backend?  I.e., if there is an optional element in
the glue schema, and the database does not have a value for that
element, that element's name is still returned in the list?  That was
not clear to me, thanks.


Best, Andre.


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