commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Dalquist <>
Subject Re: [codec-multipart] Who's In Charge
Date Fri, 02 Jul 2004 01:30:44 GMT
Sounds good. I'm working on a streamable, thread safe version right now. 
If you have an instant messenger I'd like to talk with you more about 
some of the APIs that needed to be created for the streamable side of it.

-Eric Dalquist

Mark R. Diggory wrote:

> Yes, I would say that getting some implementation in place which is 
> efficient and streamable is more important that working getting it to 
> plug into other Encoder/Decoder interfaces.
> I ran out of time to push this forward. If your interested in moving 
> it forward, it would be helpful. I think that maintaining the 
> Streamability and the extensibility in the Parts interfaces are most 
> important. I think we had ideas that this could get used for both 
> httpclient and of Decoding the multipart post requests in FileUpload 
> as well. There is definitly need for a standard codec for multipart 
> post which can get reused in these projects.
> I'll be glad to apply any patches you can supply via the bugzilla

> -Mark
> Eric Dalquist wrote:
>> I don't see plugability as being a requirement. A streaming 
>> encoder/decoder is a larger requirement as the data being encoded 
>> into a multipart message could be quite large and forcing the user to 
>> store it in memory wouldn't be very nice. I'm doing some more 
>> re-working on the codec-multipart code so it supports streams as 
>> well. I tried emailing Mark directly, I'll see what he says about the 
>> whole thing when he gets back to me. Once I get a better re-work of 
>> the code done what should I do? I'm very interesting in adding this 
>> code to the codec project.
>> -Eric Dalquist
>> Gary Gregory wrote:
>>>> Thinking more about the structure of the Encoder and Decoder
>>> interfaces
>>> I've never been crazy about these various interfaces. In our company's
>>> product at least, we've never needed pluggable impls. Some of the 
>>> Codecs
>>> are so different that it does not look like being able to replace one
>>> with another makes sense. OTOH, having interfaces gives you the option
>>> of using and creating pluggable guys, which is fine.
>>> All of this to say that I would not initially worry that much about
>>> fitting a new package in these interfaces unless you believe that
>>> "plugability" is a requirement.
>To unsubscribe, e-mail:
>For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message