The best place to track this for now is Bugzilla I think. Create a ticket and attach your code as a CVS diff patch file.
Gary > -----Original Message----- > From: Eric Dalquist [mailto:[EMAIL PROTECTED] > Sent: Thursday, July 01, 2004 14:10 > To: Jakarta Commons Developers List > Subject: Re: [codec-multipart] Who's In Charge > > 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. > > > > > > > >>of the encoder would be via an InputStream. > >> > >> > > > >This is indeed quite different from the current design. There have been > >discussions on this list about stateful and streamable decoder. > > > >Perhaps now is the time to revive these discussions. > > > >Gary > > > > > > > >>-----Original Message----- > >>From: Eric Dalquist [mailto:[EMAIL PROTECTED] > >>Sent: Thursday, July 01, 2004 11:26 > >>To: Jakarta Commons Developers List > >>Subject: Re: [codec-multipart] Who's In Charge > >> > >>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 > >>> > >>> > >>> > >>> > >>> > >>>>-----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 > >>>> > >>>> > >>>> > >>>> > >>>project > >>> > >>> > >>> > >>> > >>>>in the commons sandbox. I have some changes that I really would like > >>>> > >>>> > >>>> > >>>> > >>>to > >>> > >>> > >>> > >>> > >>>>discuss with the maintainer. > >>>> > >>>>-Eric Dalquist > >>>> > >>>>Eric Dalquist wrote: > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>>I needed to find a way to reconstruct a submitted multipart form > >>>>> > >>>>> > >>>>> > >>>>> > >>>from > >>> > >>> > >>> > >>> > >>>>>the 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 > >>>>> > >>>>> > >>>>> > >>>>> > >>>did > >>> > >>> > >>> > >>> > >>>>>make some rather extensive changes to the way it functions to make > >>>>> > >>>>> > >>>>> > >>>>> > >>>it > >>> > >>> > >>> > >>> > >>>>>fit 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 > >>>>> > >>>>> > >>>>> > >>>>> > >>>my > >>> > >>> > >>> > >>> > >>>>>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 > >>>>> > >>>>> > >>>>> > >>>>> > >>>source. > >>> > >>> > >>> > >>> > >>>>>-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] > >> > >> > > > > > >--------------------------------------------------------------------- > >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]
