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
|