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
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
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
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.
personal-viewpoint author=craigmcc
As a major proponent of long-term support
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
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
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
: 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 to understand more fully
its capabilities. j2sdk nio provides
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
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 Developers List'
Subject: RE: [codec] Streamable Codec Framework
Hello
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
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 which
.
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 Framework
Hello,
Streamable codecs make a lot of sense for some codecs
that 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 Framework
There seemed
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 List'
Subject: RE: [codec] Streamable Codec
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.
A
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 is stuck
working on some legacy code, they shouldn't
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
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.2.2 should be our LCD for codec
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).
[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-
From: Tim O'Brien [mailto:[EMAIL PROTECTED]
Sent: Monday, November 10
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
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 conversions.
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 functionality
than it currently has.
Some of the goals
-
From: Brett Henderson [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 functionality
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 have a lot to learn
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 need for
Hi All,
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 need for streamable codecs
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
29 matches
Mail list logo
