Alex Karasulu wrote:
<snip/>
When I think about this, I come back to the Architecture used for the JAXP Transformer Source and Result objects.
Is there some documentation on this architecture out there? Might be
good for me to look it over. BTW, although not directly related to JAXP
architecture specifically we looked at SAX while opting to go with the
callback mechanism. The DecoderCallback is analogous to the SAX
handler.
The Source interface is rather sparse, http://java.sun.com/xml/jaxp/dist/1.1/docs/api/javax/xml/transform/Source.html
I suspect there is some reflection used to get at the various implementations. You would probibly want something a little smarter than that, for instance in SAX's InputSource, there are methods to setup Readers or InputStreams of the wrapped content (getByteStream, and getCharStream). These allow almost anything you can send through a Reader or InputStream to be wrapped.
http://java.sun.com/xml/jaxp/dist/1.1/docs/api/org/xml/sax/InputSource.html
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.
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?
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".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?
In either case the API user will still have to castThe point is that in the Codec you just use the methods available in EncodedSource, no casting to a specific implementation.
a general interface to get at a more specific implementation.
Much of these probibly already exist in your code, this would be a refactoring of those implementations out into new classes implementing the interface. I would look at it initially as writing a "wrapper" for byte[] that looks like the methods in ByteBuffer that you have used in your code.Furthermore an extra wrapper object implementing EncodedSource would need to be defined and instantiated in order to carry the byte[] or ByteBuffer: referring here to the ByteArraySource and ByteBufferSource implemenations respectfully.
-Mark
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
