Alex,
Sorry about the delay. I'm a bit snowed under at the moment.
I've attached producers/consumers that process Object instances instead of
type specific data.
Some differences between these interfaces and those you've already built
are:
1. These have no monitor facility. All errors result
Alex,
I haven't had a chance to respond to your email yet. I'll try to do so
tonight.
I'll knock up a couple of quick interfaces for comparison at the same time.
Cheers,
Brett
-Original Message-
From: Alex Karasulu [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 24 March 2004 12:23 PM
-Original Message-
From: Noel J. Bergman [mailto:[EMAIL PROTECTED]
Sent: Monday, 8 March 2004 3:25 PM
To: Jakarta Commons Developers List
Subject: RE: [codec] StatefulDecoders
Consider the Cocoon (http://cocoon.apache.org/) pipeline for the
concept of
a fully event-driven
Take a look at the Reclaiming Type Safety section in this
article on the
event notification pattern here:
http://members.ispwest.com/jeffhartkopf/notifier/
Cool, that's a neat way of achieving type safety. Avoiding downcasts (eg.
Object to byte[]) is a good thing. It still relies
How about we put our minds together and finalize some of this
stuff so I can
start writing some codecs that can be added back to this project?
Yeah definitely, sounds like we're trying to solve the same problem here.
I haven't responded to your previous emails because I haven't contributed
Noel,
Sorry about the delay, I've been away for a few days.
In general, I have long preferred the pipeline/event model to
the approach
that Alex had, where it would give data to the codec, and
then poll it for
state. However, I don't see something in your implementation
that I think
I probably sound like a broken record but here goes :-)
If I'm barking up the wrong tree, let me know and I'll stop making noise on
this list ...
Many of the problems being discussed here have been solved in the library
I've posted previously. An up-to-date version can be found here:
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
Thanks for the reply.
Yep, it is a completely different framework. I wrote
the framework before looking at the current commons codec
component so there are no relationships between the two. Hopefully
there are ways of incorporating ideas between the two.
Are you hoping to incorporate streamed
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
(3) Should the Producer/Consumer framework submitted be
retrofitted into the current [codec] Encoder/Decoder
framework? Personally, I like the specificity of Encoder
and Decoder for interfaces. This means the current i/f
would be expanded.
I'm not terribly attached to Producer and
It is accomplished under jakarta-commons-sandbox/codec-multipart.
(2) Can we agree on /what/ streamable codecs are (sorry but
I like to
point out the obvious when starting something like this). Recognize
the current impls alternatives.
Yes sorry, I think there are two ideas
[snip]
1. Commons exists as an effort to encourage code reuse. The
Streamable framework presented was interesting, but I'd like us to
find an existing streamable Base64 implementation inside of the ASF
codebase.
Not for Base64 but Ant has:
o MD5 and SHA checksum computation:
Here are a few good rules of thumb:
1. Commons exists as an effort to encourage code reuse. The
Streamable
framework presented was interesting, but I'd like us to find
an existing
streamable Base64 implementation inside of the ASF codebase.
I have no problems with this but so far I
There are obviously advantages to having a single unified framework
and if possible it would be the ideal result. Unfortunately
I have run
into performance disadvantages so far. I haven't tried it
for a while
but in the past my base 64 conversion has not been as fast as the
Thanks for the reply.
Yep, it is a completely different framework. I wrote
the framework before looking at the current commons codec
component so there are no relationships between the two.
Hopefully there are ways of incorporating ideas between the
two.
Are you hoping to incorporate streamed
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
1.2.2 it is then :-)
I agree with maintaining 1.2.2 compatibility, it
is a bit harsh to require 1.4 to perform base64 encoding.
Unfortunately it would make life a lot easier with regards
to charset encoding ...
It should be possible to use OutputStreamWriter and
InputStreamReader internally to
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.
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
23 matches
Mail list logo
