[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] Getting control over the input stream


Thanks.  I will try to flip things around and push data through the chain rather than pulling.

Jeff



Scott Lewis <slewis@xxxxxxxxxxxxx>
Sent by: ecf-dev-bounces@xxxxxxxxxxx

08/31/2007 03:23 AM

Please respond to
"Eclipse Communication Framework \(ECF\) developer mailing list."        <ecf-dev@xxxxxxxxxxx>

To
"Eclipse Communication Framework (ECF) developer mailing list." <ecf-dev@xxxxxxxxxxx>
cc
Subject
Re: [ecf-dev] Getting control over the input stream





Hi Jeff,

Jeff McAffer wrote:


Is there a way to use ECF for file transfer but rather than have it suck the stream of bytes, basically get it to setup everything and then let someone else pull the bytes as needed?  


ECF was designed to be asynchronous (non-blocking), and so introducing blocking/stream-based I/O wasn't the original API intention.  

However, I think it would be straightforward to use PipedInputStreams (as the InputStream returned from some new wrapper class), and PipedOutputStream (the OutputStream passed to ECF in the IIncomingFileTransferReceiveStartEvent.receive(OutputStream) call.  This way, ECF would asynchronously write to the given output stream as data are received and some other thread could read the connected PipedInputStream, and block when no data are available.

Such an API can be added to ECF, or to existing provisioning classes, if desired.  Please file an enhancement request and we will address it.

But one thought:  do you want to have the chain of processors be InputStream-based?  Of course this means having ioexception/failure catching in code that may not be well-suited to handle it (e.g. transformers)...among other things.

I have two usecases
1) in the new provisioning work (p2) there should be an API that returns an InputStream on an artifact

2) using this InputStream we can setup a chain of processors that take InputStreams, transform the content and give back InputStreams


In the end the we'd use a transfer bytes style method that reads from the InputStream and writes to some OutputStream.  So in essence #2 wants to put arbitrary processing between the real source and the destination OutputStream.  #1 is an escape mechanism that allows people to do things we did not think of. They need to be in control of how and when the bytes are pulled.


Thanks

Jeff




_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev
 

_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev