On Wed, Oct 14, 2009 at 10:28 AM, David Latorre <[email protected]> wrote: > This is I what I first thought but I think this might imply several > risks in terms of performance, or the need to store the whole > transferred file locally (be it in memory or disk). This is of course, > if he cannot use PipedStreams.
As far as I can see he should be able to use PipedStreams, that was what I was suggesting :-) > - If you are using different threads for the FTP transfer and the > transfer to Amazon I guess you could use PipedStreams with our current > code (I haven't looked at it actually). Agreed > If no one comes up with a solution for this, i don't think we should > dismiss the possibility of exposing the input stream, what do you > think niklas? I don't think we should do it as part of our public API. The public API is DataConnection. Which would mean that any refactoring of IODataConnection would potentially change how it works internally and thus break this type of application. /niklas
