commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark R. Diggory" <>
Subject Re: [codec-multipart] Who's In Charge
Date Fri, 02 Jul 2004 01:24:13 GMT
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


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.

View raw message