Mark,
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.
<snip/>
> >>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.
WDYT?
Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
