[saga-rg] proposal for extended file IO

[Andrei Hutanu]

This is an interesting discussion.
I don't oppose of specifying a mechanism
to support any high-level operations in SAGA .. but
isn't any mechanism you can agree on going to
be limited and limiting (Jon M. had a good example and
I can come up with a couple examples myself) and the preferred way of 
doing this is going to be
to use complementary data selection mechanisms (perhaps grid services) + 
SAGA binary pipes ?

Isn't data selection too application specific to be included in this?

Andrei

I am personally going to use different mechanisms

>  
>
>>I simply fear we'll have the same problems we have with the GAT today. The
>>GAT API is in principle usable in a broad range of use cases based on a
>>generic API. The genericity is ensured by using key/value tables in the API
>>itself, allowing quick adaptation to any concrete need. The problem is the
>>missing specification of these key/value pairs which makes it difficult to
>>achieve reusability.
>>    
>>
>
>I absolutely agree that the problem lies right there:
>semantic overloading of strings.  The situation is somewhat
>better than in GAT though:
>
>  - the preferences in GAT are really generic, and can be
>    used for anything.  The eModes have a very limited
>    scope, and are hence much easier to agree on between
>    different implementations
>
>  - as the mapping to GridFTP is 1:1, and GridFTP is quite
>    commonly used, so there is at least some other instance
>    to be used for agreement on the modes.  Hence, every
>    implementation of a eMode can be expected to do the same
>    thing. At least there is a good chance for that.
>
>However, again: you are right.  Semantic overloading of
>strings is not a nice thing to do, and is here only
>justified by a lack of obvious alternatives.
>
>Thanks, Andre.
>
>  
>
>>Regards Hartmut
>>
>>    
>>
>
>
>
>  
>