commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <ggreg...@seagullsw.com>
Subject RE: [codec] StatefulDecoders
Date Tue, 24 Feb 2004 23:37:32 GMT
I think you are barking up the right tree ;-)

It is just quite a bit of work to integrate a new framework into [codec]. I
mean do we: (1) Find a way to merge the two, or (2) deprecate the old in
favor of the new making sure that all the old features exists in the new. I
have not looked at the new enough stuff to make intelligent comments.
Unfortunately, I do not have much time right now for this. Hopefully others
will opine.

Gary

> -----Original Message-----
> From: Brett Henderson [mailto:jakarta@bretth.com]
> Sent: Tuesday, February 24, 2004 14:53
> To: 'Jakarta Commons Developers List'
> Subject: RE: [codec] StatefulDecoders
> 
> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message