Quoting [Andrei Hutanu] (Jun 13 2005):
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)
I would welcome more examples! :-)
and the preferred way of doing this is going to be to use complementary data selection mechanisms (perhaps grid services) + SAGA binary pipes ?
How would that work? Outside of SAGA I see what you mean, but in SAGA we have no (and intent no) generic mechanism to access a Grid Service, and to perform generic custom operations.
Isn't data selection too application specific to be included in this?
Ah, but the application specific part is NOT part of the eRead proposal - that merrily provides a placeholder for doing that in a clean way! Think URLs: if you open a remote file, the URL is a String, basically, and allows you to encapsulate some semantics which are transparent to the API: This is NOT a file, but can be opened as a file: http://www.google.com/search?q=SAGA&btnG=Search+the+Web So, an URL is a placeholder for additional semantic information. eRead is similar: the emode and the spec strings are placeholders for semantic information neccessary to perform the read.
Andrei
I am personally going to use different mechanisms
Which ones? ;-) Cheers, Andre.
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
-- +-----------------------------------------------------------------+ | Andre Merzky | phon: +31 - 20 - 598 - 7759 | | Vrije Universiteit Amsterdam (VU) | fax : +31 - 20 - 598 - 7653 | | Dept. of Computer Science | mail: merzky@cs.vu.nl | | De Boelelaan 1083a | www: http://www.merzky.net | | 1081 HV Amsterdam, Netherlands | | +-----------------------------------------------------------------+