[SAGA-RG] FW: ISN spec

[Steve Fisher]

On 18 March 2011 16:03, Andre Merzky <andre at merzky.net> wrote:
> 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?

It is only because we saw no benefit in adding the async complexity.
If we add it to ISN then it really needs adding to SD as well. I will
discuss the consequences directly with you in Taipei.


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

It would be very inefficient to look at the data to determine the set
of related entities. This is just information from the schema.

Steve

>
>
> Best, Andre.
>
>
> --
> So much time, so little to do...
> [Garfield]
> --
>  saga-rg mailing list
>  saga-rg at ogf.org
>  http://www.ogf.org/mailman/listinfo/saga-rg
>