[saga-rg] proposal for extended file IO

[Andrei Hutanu]

You're right .. _I_ will not use it. It
will not give me the performance I need.
My only concern is that if it gets included, other people
might believe that it is a good model and use it :)
only to find out later what the problems are.

Andrei

>Hi 
>
>>>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!
>>>      
>>>
>>I was thinking that the data selection operation as
>>described in the proposal is a very specific operation and
>>that there might be many remote data operations that
>>cannot be covered by this. For example when I think of
>>remote data selection I think more in terms of starting a
>>remote job (using SAGA),  communicating with the job using
>>specific protocols (perhaps grid services implemented on
>>top of the SAGA streams) and transferring data from the
>>remote job locally using SAGA streams. The job itself is
>>using SAGA to access the file.
>>
>>There's a lot of SAGA involved here but there is no eread
>>and using eread would be a limiting factor.  Eread
>>basically means (start job, send command, receive
>>response, end job).  That's perhaps a limiting model for
>>remote data access.
>>    
>>
>
>I think I understand the scenario you describe, and you are
>right: eread is not a good model to implement that, neither
>is any of the other file I/O operations we have, or have
>been proposed.  Its a client server scenarios, and streams
>will do fine.
>
>So, if eread does not fit, and read does not fit, don't use
>it.  So, how is their existence limiting your scenario?  
>
>I think I am missing the point (seem to do that a lot
>lately)...
>
>Cheers, Andre.
>
>
>  
>
>>My 2 cents, Andrei
>>    
>>
>
>
>
>  
>