commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: [codec] Stateful/Streaming/Chunking Codecs
Date Mon, 05 Jul 2004 20:06:30 GMT

Excuse me for taking so long before a reply.  I've been thinking about
your recommendations a bit.  There are several issues that come to mind
regarding NIO and in terms of general API use cases.  I'll try to
outline these issues below in context.


> >>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 { ...
> >>    
> >>
> >
> >I like this approach.  What would the EncodedSource interface look like
> >or is it just a marker interface?
> >
> >  
> >
> I suspect it would probibly look alot like a limited version of 
> ByteBuffer in that where ever you called methods in ByteBuffer in the 
> Implementation, then the interface could supply something similar for 
> byte[] or whatever was the storage/stream underneath.

First the EncodedSource idea would work well if we could get it to work
with NIO Channels but I don't think that's possible without subclassing
ByteBuffer.  SocketChannel for example reads into a ByteBuffer using the
read() operations that takes either a ByteBuffer argument or a
ByteBuffer[] argument: the same situation exists for the opposite
direction with write() operations on channels.  I can't seem to think of
a clean way around this.

We could create our own Channel implementation to wrap other Channels. 
Such a channel would overload the read() and write() methods to accept a
EncodedSouce argument.  Note that this would get even more complex once
Selectors are considered with non-blocking IO.  This approach worries me
because it seems to incur more complexity for a tiny reward.  It leads
me to question whether we should even bother being backwards compatible
with JDKs before 1.4 which are rapidly approaching their end of life.  

> >>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).
> >
> >That's most excellent; this is the goal we are all trying to achieve. 
> >The use of EncodedSource makes the API more explicit in the fact that it
> >operates upon some 'encoded' substrate btw.  It will give the API a
> >better defined symetry when we confront the Encoder interfaces.
> >
> >If you'll permit me to play devil's advocate, let me ask what difference
> >is there in casting a EncodedSource to a
> >ByteArraySource/ByteBufferSource from casting an Object to a
> >byte[]/ByteBuffer?  
> >  
> >
> You can control the API and encapsulate that which makes the substrate 
> unique behind the interface, then your not implementing the Codec for 
> every type of Substrate out there, just implementing the EncodedSource 
> "wrapper".
> >In either case the API user will still have to cast
> >a general interface to get at a more specific implementation. 
> >
> >  
> >
> The point is that in the Codec you just use the methods available in 
> EncodedSource, no casting to a specific implementation.

I can't see how this would be possible with ByteBuffer to get them to
work with Channels which is the whole point to their existance IMO. 
However perhaps you might find a way to do this which I'm not seeing at
the moment.  Do you mind taking a look at the NIO APIs to see if there
is some way?

What I would like to do right now is start carving out the encode half
of these APIs as they are right now.  Then I will implement a simple
encoder/decoder pair just to look at the use cases for both NIO users
and traditional IO users.  Then I would like to take a step back to see
how we can inject these ideas into the API.  I'll probably choose a
really simple codec like Hex to binary transformations for the example. 
You're welcome to join in the pursuit if you like: I have the code up on
the directory project's snickers project for now.  This way we can have
a real example to work with and see how different patterns change the
way the API is used.  



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message