> 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
21 matches
Mail list logo
