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
http://issues.apache.org/bugzilla/enter_bug.cgi?product=Commons&version=unspecified&component=Sandbox&rep_platform=Other&op_sys=other&priority=Other&bug_severity=normal&bug_status=NEW&assigned_to=&cc=&bug_file_loc=&short_desc=%5Bcodec-multipart%5D&comment=&maketemplate=Remember+values+as+bookmarkable+template&form_name=enter_bug
-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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]