commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@bluewin.ch>
Subject RE: [codec] RFC1522 codecs & partial implementation of quoted-printable codec
Date Thu, 18 Mar 2004 21:59:34 GMT
Gary,
It'll split the patch into four smaller ones which can be dealt with one
after another. I'll start with the small tweaks I have made to the
URLCodec with the quoted-printable codec, Q-codec, and B-codec following
shortly

Oleg

On Thu, 2004-03-18 at 02:34, Gary Gregory wrote:
> Oleg,
> 
> This all sounds good to me. I am happy to have codec become more useful
> to httpclient as bits get moved or created in the right place.
> 
> Looking at the Bugzilla ticket, I think it would make it easier for all
> (at least I'd like it that way ;-) if you could create one ticket per
> codec: quoted-printable codec, Q-codec and B-codec. This would make it
> easier to integrate new code when you/we deem it is fine for nightly
> builds. Unit tests are a must of course! Some Javadocs would be nice too
> ;-) Perhaps not 100% complete at this stage but at least enough for
> others to grok the pile.
> 
> I think codec can stay 1.2 compliant for quite a while, at least until
> the streamable and/or stateful codec f/w appears. Even then I would hope
> that compatibility can be achieved even if it means shipping a
> 1.4-codec-add if streamable and/or stateful codec need to use NIO.
> 
> Thanks!
> Gary
> 
> > -----Original Message-----
> > From: Oleg Kalnichevski [mailto:olegk@bluewin.ch]
> > Sent: Wednesday, March 17, 2004 15:39
> > To: Jakarta Commons Developers List
> > Subject: RE: [codec] RFC1522 codecs & partial implementationofquoted-
> > printable codec
> > 
> > Gary,
> > We do need Q-codec in [HttpClient] one way or another, either as a
> part
> > of [HttpClient] package itself or as a service provided by [Codec].
> The
> > problem is that [HttpClient] must stay compatible with Java 1.2 at
> least
> > for another major release. Therefore I'd like to get all the codecs
> that
> > [HttpClient] needs for the 3.0 release in the 1.x branch of [Codec]
> > before the new framework is introduced and (potentially) renders
> [Codec]
> > HEAD Java 1.2 incompatible.
> > 
> > Oleg
> > 
> > On Thu, 2004-03-18 at 00:18, Gary Gregory wrote:
> > > Hello,
> > >
> > > As the [HttpClient] post-2.0 nightly drops now include [codec] 1.2,
> > > primarily to reuse Base64 IIRC (and the URL codec?), it would make
> sense
> > > to move or implement more codecs in [codec].
> > >
> > > With this in mind, I would look at the [HttpClient] code base and
> ask
> > > the [HttpClient] folks what they think.
> > >
> > > Since HttpClient now ships with codec, I am all for having the right
> > > bits in the right place.
> > >
> > > Gary
> > >
> > > > -----Original Message-----
> > > > From: Oleg Kalnichevski [mailto:olegk@bluewin.ch]
> > > > Sent: Wednesday, March 17, 2004 14:45
> > > > To: Jakarta Commons Developers List
> > > > Subject: [codec] RFC1522 codecs & partial implementation ofquoted-
> > > > printable codec
> > > >
> > > > Gary,
> > > > I have submitted quite a while a draft implementation of three new
> > > > codecs:  quoted-printable codec (partial implementation), Q-codec
> and
> > > > B-codec. Nothing terribly exiting, but all there may come quite
> handy
> > > in
> > > > [HttpClient] and [FileUpload].
> > > >
> > > > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26617
> > > >
> > > > Shall I continue working on these codecs or there is no interest
> of
> > > what
> > > > so ever?
> > > >
> > > > Oleg
> > > >
> > > > On Wed, 2004-03-17 at 22:27, Gary Gregory wrote:
> > > > > FYI, please see the RELEASE-NOTES.txt file in CVS for a current
> look
> > > at
> > > > > what a 1.3 would contain. I think the file is up to date. If
> not,
> > > let
> > > > > this list know.
> > > > >
> > > > > Gary
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Gary Gregory [mailto:ggregory@seagullsw.com]
> > > > > > Sent: Wednesday, March 17, 2004 13:15
> > > > > > To: Jakarta Commons Developers List
> > > > > > Subject: RE: [codec] preparing for another release?
> > > > > >
> > > > > > Indeed, I had suggested a release schedule around the new
> major
> > > codec
> > > > > > work:
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Gary Gregory [mailto:ggregory@seagullsw.com]
> > > > > > Sent: Wednesday, February 25, 2004 13:21
> > > > > > To: 'Jakarta Commons Developers List'
> > > > > > Subject: [codec] Possible 1.3 and beyond?
> > > > > >
> > > > > > Hello all,
> > > > > >
> > > > > > Since the current discussions around stateful and streamable
> > > decoders
> > > > > > all involve introducing a new and better architecture I am
> > > wondering
> > > > > if
> > > > > > we should:
> > > > > >
> > > > > > (1) Release a version 1.3 soon to gather all of the fixes and
> > > > > > improvements since the November 1.2 release and,
> > > > > >
> > > > > > (2) then work on the new code and plan for a 1.4 to introduce
> the
> > > new
> > > > > > architecture?
> > > > > >
> > > > > > Gary
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Alex Karasulu [mailto:aok123@bellsouth.net]
> > > > > > > Sent: Wednesday, March 17, 2004 11:41
> > > > > > > To: 'Jakarta Commons Developers List'
> > > > > > > Subject: [codec] preparing for another release?
> > > > > > >
> > > > > > > Greg,
> > > > > > >
> > > > > > > Are you prepping for another release before looking into
> some of
> > > > > > > these Stateful codec matters?  I think you or someone else
> may
> > > > > > > have mentioned it at some point but I forget.
> > > > > > >
> > > > > > > Alex
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > >
> > >
> ---------------------------------------------------------------------
> > > > > > > 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
> 


---------------------------------------------------------------------
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