Alex Karasulu wrote:
Ooops looks like this only went out to Mark's address.
Alex
On Fri, 2004-07-02 at 11:19, Alex Karasulu wrote:
On Fri, 2004-07-02 at 10:49, Mark R. Diggory wrote:
Alex,
This looks very good.
Hey thanks Mark! But I still think we can do better I just don't know how at this point. I'm looking for others to provide their input in this discovery process.
I think that a Stateful Codec with monitoring would be a powerfull feature for multipart-codec.
Gary, Tim, Brett, Noel and I were discussing the addition of this stuff in whatever form it may take to the codec proper. Then perhaps the multipart-codec could just use it: I'm presuming that multipart-codec has a dependency on commons-codec.
I'm not experienced with NIO, IS this API restircted to working with just NIO?
No, it can be used outside of NIO and with JDK's below 1.4. I tried to generalize the stateful codec API as much as possible to avoid a dependency on ByteBuffer which would then impose the NIO and hence JDK1.4 requirement.
Its great this kind of thought went into it.
When I think about this, I come back to the Architecture used for the JAXP Transformer Source and Result objects.This was something that came up when we had a discussion a while back on this list with the proposed API at that time. I generalized it by using an Object instead of ByteBuffer on the decode() and decodeOccurred() methods of the Decoder and DecorderCallback interfaces respectively.
So instead of passing around a ByteBuffer you can pass around a byte[]
if you do not want to be using NIO. However the complete benefits of
this API are felt when used with non-blocking IO as provided by NIO. However you do not have to use it because of the generalization.
I currently have the problem where some folks think it is too general by avoiding this dependency on NIO and JDK1.4 and up environments. They prefer a more specific API with ByteBuffer. I have my own opinions on the matter as well but they change so I still need to feel out the community some more.
Alex
so in StatefulDecoder you have
void decode( Object encoded ) throws DecoderException ;
What about something like:
void decode( EncodedSource source ) throws DecoderException ;
then you can have
ByteBufferSource implements EncodedSource { ...and
ByteArraySource impements EncodedSource { ...The Source Implementations are responsible for those aspects that make them NIO or not, then the Decoder itself stays generic and can even be reused across different Source Implementations (Similar to how JAXP can have a DOMSource, StreamSource or SAXSource).
-Mark
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
