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