Quoting Oleg Kalnichevski <[EMAIL PROTECTED]>:
> > The most important phrase in Craig's email was: "As such, I'm
> > personally not interested in working on any revolutionary Struts or
> > Commons designs that do not presume at least J2SE 1.4 / J2EE 1.4 as the
> > base platform as the minimum
Oleg Kalnichevski wrote:
The most important phrase in Craig's email was: "As such, I'm
personally not interested in working on any revolutionary Struts or
Commons designs that do not presume at least J2SE 1.4 / J2EE 1.4 as the
base platform as the minimum requirement."
Tim & Craig,
I wish I
A +1 for Craig's comments.
If there are users who still have 1.2 requirements going forward, I say
should say to them, you need to take it upon yourself to make the case
for an upgrade, or work actively in this community to write components
that work with 1.2.
The most important phrase in Crai
Quoting Gary Gregory <[EMAIL PROTECTED]>:
> (1) "eventually" is, sadly I think, a ways off in the future. See
> discussions on this list WRT J2ee containers, WebSphere, most common
> installed base of such containers, etc.
>
As a major proponent of long-term support for existing packages that
> Maybe this is what you were saying and I misunderstood you. Either way,
> it's painful to not be able to use 1.4, especially with 1.5's new tricks
> on the horizon. ;)
I think I like your approach better even with the extra layer.
Gary
Gary Gregory wrote:
(2) What could be done, and please forgive my lack of intimacy with these
APIs, is to create [codec] APIs that are forward compatible to any extent
possible. What I mean by this if NIO has a class Foo with methods a() and
b(Foo) is to create an equivalent [codec] class Bar with
iggory [mailto:[EMAIL PROTECTED]
> Sent: Thursday, January 15, 2004 09:38
> To: Jakarta Commons Developers List
> Subject: [codec] More thoughts on CharSets and Encoders (references: RE:
> [codec] Streamable Codec Framework)
>
> I've been heavily reviewing the NIO api in 1.4
> Does CharSet/Util's in [lang] approach a similar
> functionality to nio.charset? After reviewing the codebase,
> my viewpoint is no, as it is more for "building" charsets,
> than for using them (authors rebuttals always welcome).
I'd also be interested to see if this functionality exists
some
I've been heavily reviewing the NIO api in 1.4 to understand more fully
its capabilities. j2sdk nio provides Charsets (ServiceProviders,
Encoders, Decoders)
http://java.sun.com/j2se/1.4.2/docs/api/java/nio/charset/package-summary.html
http://java.sun.com/j2se/1.4.2/docs/api/java/nio/charset/spi/Cha
> I suspect we are going to need something along the lines of a
> "Streamable Encoder/Decoder" for the Multipart stuff. If we look at
> HttpClients MultipartPostMethod, there is a framework for basically
> joining multiple sources (files, strings, byte arrays)
> together into an
> OutputStream
I'm not familiar with streaming issues but this sounds similar to the
stuff in javax.sound.sampled, there might be some reusable patterns there.
Emmanuel Bourg
Mark R. Diggory wrote:
Brett,
I suspect we are going to need something along the lines of a
"Streamable Encoder/Decoder" for the Mult
relevant Consumer/Producer implementations to interact
with them. Codec algorithms won't require modification.
Cheers,
Brett
> -Original Message-
> From: Gary Gregory [mailto:[EMAIL PROTECTED]
> Sent: Friday, 9 January 2004 4:15 PM
> To: 'Jakarta Commons
ct
with them. Codec algorithms won't require modification.
Cheers,
Brett
> -Original Message-
> From: Gary Gregory [mailto:[EMAIL PROTECTED]
> Sent: Friday, 9 January 2004 4:15 PM
> To: 'Jakarta Commons Developers List'
> Subject: RE: [codec] Streamable Codec F
Encoder.encode(Object) should also handle
I/O/Streams and Reader/Writer...
Gary
> -Original Message-
> From: Brett Henderson [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, January 06, 2004 18:29
> To: 'Jakarta Commons Developers List'
> Subject: RE: [codec] Streamable Codec Fr
low
message as an example because I believe it is more
effective to discuss working code than talk about
abstract ideas.
> -Original Message-
> From: Brett Henderson [mailto:[EMAIL PROTECTED]
> Sent: Thursday, 13 November 2003 10:33 AM
> To: 'Jakarta Commons Developers Lis
I made some changes to the code I supplied previously, it can
be found at the following URL.
http://www32.brinkster.com/bretthenderson/BHCodec-0.5.zip
The main differences relate to the codec interfaces and support
for data types other than "byte", the encoding algorithms
are largely unchanged.
My apologies as well, I didn't realize you weren't a committer, nor that
the MD5 stuff never made it into the release.
Tim, everyone, now that codec is a released component, might we create a
contrib directory or a codec-sandbox? Chris's MD5 stuff has been done
for ages now.
I am not a common
ary Gregory [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, 11 November 2003 4:19 AM
> To: 'Jakarta Commons Developers List'
> Subject: RE: [codec] Streamable Codec Framework
>
>
> Yes, no problem, 1.2.2.
>
> Gary
>
> > -Original Message-
> >
Apologies, that was not intended for the entire list. But since it went
there, may as well elaborate.
The ChunkedInputStream used a call-back system to provide a data written
to the stream back in consistently-sized chunks (except for the last
data written, which would be sized appropriately). Th
I don't have CVS access! But you do, and you should have a copy of the
code...
- siege
On Mon, 2003-11-10 at 15:27, Ryan Hoegg wrote:
> IIRC, Chris O'Brien had a ChunkedInputStream for the MD5 digest code he
> put together. If it's not in CVS, Chris, put it there!
>
> --
> Ryan Hoegg
> ISIS Ne
Yes, no problem, 1.2.2.
Gary
> -Original Message-
> From: Tim O'Brien [mailto:[EMAIL PROTECTED]
> Sent: Monday, November 10, 2003 08:10
> To: Jakarta Commons Developers List
> Subject: RE: [codec] Streamable Codec Framework
>
> Oleg, this is understood - 1
Tim, Gary, et al
Streamable codec framework would be a welcome addition to Commons Codec.
However, as far as we (Commons HttpClient) are concerned, the decision to
ditch java 1.2.2 support would render Codec unusable for us (and I'd guess
a few other projects that still need to maintain java 1.2.2
day, November 09, 2003 21:06
> To: Jakarta Commons Developers List
> Subject: RE: [codec] Streamable Codec Framework
>
> Well, not so fast, I thought that the general Jakarta Commons rule was
> 1.2 compatibility.
>
> The reasoning here is that, if some unfortunate programmer i
t;
> Gary
>
> > -Original Message-
> > From: Brett Henderson [mailto:[EMAIL PROTECTED]
> > Sent: Sunday, November 09, 2003 19:26
> > To: 'Jakarta Commons Developers List'
> > Subject: RE: [codec] Streamable Codec Framework
> >
> >
n [mailto:[EMAIL PROTECTED]
> Sent: Sunday, November 09, 2003 19:26
> To: 'Jakarta Commons Developers List'
> Subject: RE: [codec] Streamable Codec Framework
>
> I think the design of the codec framework could cover
> your requirements but it will require more
I think the design of the codec framework could cover
your requirements but it will require more functionality
than it currently has.
> > > > Some of the goals I was working towards were:
> > > > 1. No memory allocation during streaming. This eliminates
> > > > garbage collection during large con
> > > Some of the goals I was working towards were:
> > > 1. No memory allocation during streaming. This
> > > eliminates
> > > garbage collection during large conversions.
> > Cool. I got large conversions... I'm already at
> > mediumblob in mysql , and it goes up/down XML
> stream
> > :)
>
> I
> > I noticed Alexander Hvostov's recent email
> > containing streamable
> > base64 codecs. Given that the current codec
> > implementations are
> > oriented around in-memory buffers, is there room for
> > an
> > alternative codec framework supporting stream
> > functionality? I
> > realise the n
I just realised I left off "codec" in the subject. Sorry about
that.
-Original Message-
From: Brett Henderson [mailto:[EMAIL PROTECTED]
Sent: Monday, 3 November 2003 10:47 AM
To: [EMAIL PROTECTED]
Subject: Streamable Codec Framework
Hi All,
I noticed Alexander Hvostov's recent email c
29 matches
Mail list logo
