[saga-rg] proposal for extended file IO

[Andre Merzky]

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 at cs.vu.nl       |
| De Boelelaan 1083a                | www:  http://www.merzky.net |
| 1081 HV Amsterdam, Netherlands    |                             |
+-----------------------------------------------------------------+