commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <aok...@bellsouth.net>
Subject Re: [codec-multipart] Who's In Charge
Date Fri, 02 Jul 2004 15:25:35 GMT
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.
> 
> 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
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message