commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brett Henderson" <jaka...@bretth.com>
Subject RE: [codec] StatefulDecoders
Date Tue, 24 Feb 2004 22:53:18 GMT
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:
http://www32.brinkster.com/bretthenderson/bhcodec-0.7.zip
It uses generic interfaces for communication between all components that
allows the use of streams, byte arrays, NIO, etc to be plugged together as
necessary.  NIO isn't currently supported but I expect it would be trivial
to add it.

The library can be visualised as a collection of data consumers and
producers (a codec engine implements both).  No distinction is made between
encoding and decoding (they are the same thing in my view from an api
perspective).

One problem I see with the current codec project is that every new use case
that is envisaged tends to require extensions to the current interfaces.
The above library is designed to be more generic and allow a more pluggable
approach where new functionality doesn't impact every codec implementation.

It uses a push model internally but pull-model utility classes wrapped
around underlying push classes can be used to implement pull functionality
where necessary.

It does not require JDK1.4 although NIO could be plugged in if necessary.

I understand that people don't want to spend time looking at every pet
project people have come up with but I think this could be useful in
commons.  There is a lot to look at and I guess that is discouraging people
from taking the time to look at it.

Should I propose this library as a separate project?  (How do I do this?)
Perhaps as more generic codec library that could potentially be used by
commons-codec once it has matured.  It may be too large a change to fit into
the existing codec project as it currently stands.

I've offered this several times now and while there doesn't seem to be any
major opposition to the idea, there hasn't been strong support either.  I'm
not sure how to proceed.  Is this something that can be placed in a sandbox
for people to play with?

Cheers,
Brett

> -----Original Message-----
> From: Noel J. Bergman [mailto:noel@devtech.com] 
> Sent: Tuesday, 24 February 2004 2:25 PM
> To: Jakarta Commons Developers List
> Subject: RE: [codec] StatefulDecoders
> 
> 
> > This brings up an interesting issue: How do we potentially 
> package and
> 
> > deliver some code that depends on Java 1.4. In a second [codec] jar?
> 
> 
> 
> There are several issues, but let me address what I consider 
> to be the key
> 
> one: we have to design the core code as push-model.  If we 
> were to design
> 
> the code as pull-model, we would lose the thread of execution 
> inside the
> 
> callee.  We don't want the callee blocking on I/O and returning when
> 
> finished.  But with a non-blocking callee, we can then use 
> either a NIO or
> 
> IO wrapper as necessary.
> 
> 
> 
> Obviously the interface between the I/O handling wrapper and the data
> 
> handling core will have to be Java 2 < 1.4 compatible.
> 
> 
> 
> 	--- Noel
> 
> 
> 
> 
> 
> ---------------------------------------------------------------------
> 
> 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