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]
