commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary Gregory" <ggreg...@seagullsoftware.com>
Subject RE: [codec-multipart] Who's In Charge
Date Thu, 01 Jul 2004 21:21:00 GMT
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:edalquist@unicon.net]
> 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:edalquist@unicon.net]
> >>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:edalquist@unicon.net]
> >>>>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:
commons-dev-unsubscribe@jakarta.apache.org
> >>>>>For additional commands, e-mail:
> >>>>>
> >>>>>
> >commons-dev-help@jakarta.apache.org
> >
> >
> >>>>>
> >>>>>
> >>>>>
>
>>>---------------------------------------------------------------------
> >>>
> >>>
> >>>>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> >>>>For additional commands, e-mail:
commons-dev-help@jakarta.apache.org
> >>>>
> >>>>
> >>>>
> >>>>
>
>>>---------------------------------------------------------------------
> >>>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> >>>For additional commands, e-mail:
commons-dev-help@jakarta.apache.org
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
>
>>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> >>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >>
> >>
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
> >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message