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-multipart] Who's In Charge
Date Fri, 02 Jul 2004 15:48:58 GMT
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.

>>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
>>    
>>
When I think about this, I come back to the Architecture used for the 
JAXP Transformer Source and Result objects.

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


Mime
View raw message