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