I'm not familiar with streaming issues but this sounds similar to the stuff in javax.sound.sampled, there might be some reusable patterns there.

Emmanuel Bourg


Mark R. Diggory wrote:

Brett,

I suspect we are going to need something along the lines of a "Streamable Encoder/Decoder" for the Multipart stuff. If we look at HttpClients MultipartPostMethod, there is a framework for basically joining multiple sources (files, strings, byte arrays) together into an OutputStream which is multipart encoded. I want to attempt to maintain this strategy when isolating the code out of HttpClient and into the multipart sandbox project. I suspect that your Streamable Consumer/Producer stuff could also be advantageous for multipart encoding/decoding. At least I want to make sure we're not inventing the same wheel.

Specifically, I see we're going to need interfaces other than the existing codec ones because they pass around byte[] and Object when encoding/decoding. We need to maintain that the content will be streamed from its native datstructure when its consumed by a consumer (HttpClient MultipartPost for instance) or when it is used to "decode" that the Objects produced are built efficiently off a InputStream (ie Files are immediately written to the FileSystem, Strings or byte[]s are maintained in memory).

Either way, I'm currently "tidying" up a maven project directory to be committed into the sandbox for the new multipart codec stuff. Once, its in place we could add your code to it as well.

-Mark

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to