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:[EMAIL PROTECTED] > 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:[EMAIL PROTECTED] > > 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: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED]
