commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark R. Diggory" <mdigg...@latte.harvard.edu>
Subject Re: [codec] Stateful/Streaming/Chunking Codecs
Date Fri, 02 Jul 2004 17:05:41 GMT
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

>  
>
>>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.

>>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.

>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.
>
>  
>
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.

-Mark


Mime
View raw message