Sorry about that last reply being to the wrong email.
Thinking more about the structure of the Encoder and Decoder interfaces I need to discuss what I see as the requirements on a multipart encoder with you or someone else who is more familiar with the codec package and get your options.
The basic idea is you have a Part interface. From that there is a StringPart and a FilePart.
The MultipartEncoder would need to take an array of Parts and encode them into a multipart message. One big difference is because of the possible size of a multipart message the preferred way to get the output of the encoder would be via an InputStream. This would allow the message to be constructed on the fly and written to the caller. The caller could then write the data directly out to whatever needs it, keeping memory usage down to a minimum. I'm not sure how this method of encoding would be handled by the current Encoder interface.
Also for decoding the opposite would be true. The decoder would need to read it's data from an InputStream and return an array of parts. The decoder would provide the option for file data to be written to a user specified temp directory so the only data stored in the Part objects would be a reference to the temp file via a File object.
Let me know what you think of this.
-Eric Dalquist
Gary Gregory wrote:
Hello,
The only person I see in codec-multipart/project.xml is:
<developer> <name>Mark Diggory</name> <id>mdiggory</id> <email>mdiggory at apache.org</email> </developer>
I am the codec 1.3 release manager for now and I cannot say much about multipart apart from knowing that it exists and that volunteers are welcome.
Perhaps you could discuss on this list the pros and cons for a multipart addition to the next feature release of codec. A proposal type of thing ;-)
Gary
project-----Original Message----- From: Eric Dalquist [mailto:[EMAIL PROTECTED] Sent: Thursday, July 01, 2004 10:29 To: Jakarta Commons Developers List Subject: [codec-multipart] Who's In Charge
I'm wondering who I should talk about about the codex-multipart
in the commons sandbox. I have some changes that I really would liketo
fromdiscuss with the maintainer.
-Eric Dalquist
Eric Dalquist wrote:
I needed to find a way to reconstruct a submitted multipart form
didthe files and parameters stored in temp locations. I was directed to
the codec-multipart code and found it did part of what I wanted. I
itmake some rather extensive changes to the way it functions to make
myfit my application.
The big issues I had were with the inability to control the boundary
and the fact that by using static methods for a majority of the work
the code was not threadsafe. I would be more that willing to submit
source.changes for review and make modifications to the architecture as
needed to get the code accepted into the codec-multipart project.
Please let me know two who or where I should upload the modified
----------------------------------------------------------------------Eric Dalquist
---------------------------------------------------------------------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]
--------------------------------------------------------------------- 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]