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 20:55:43 GMT
> 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


Mime
View raw message