Hi Emmanuel, Thanks for your comments!
I imagine that slice() method would have a behaviour similar to the one of ByteBuffer. As in ByteBuffer, position based values (position, limit and mark) of the slice would be independent copies of the original IoBuffer ones, but the buffer content itself would be shared. Then, the position based values would logically be consistent between the original and the new slice. In decoders, IoBuffer would be used as a kind of sliding window, consequently position based values would be monotonically growing series (and thus limited to Integer.MAX_INT). What do you think? Currently the CumulativeByteBuffer provides most of the methods available in NIO ByteBuffer (it doesn't not offer position-aware methods, which I think are not really useful in a decoding phase). Kind regards, Raphaël On Mon, Jun 17, 2013 at 12:59 AM, Emmanuel Lécharny <[email protected]> wrote: > Le 6/16/13 9:31 PM, Raphaël Barazzutti a écrit : >> Hi Julien, >> >> Thanks for your comments! >> >> You're right there are not that much differences between that two classes. >> >> In some situations I find IoBuffer very interesting, but in the case >> of a decoder there are some concepts taken from ByteBuffer that in my >> opinion don't fit very well. >> >> Lets describe briefly a case: In a decoder, the IoBuffer could be used >> as a connection's buffer, then a given instance would be the context >> of the connection. That buffer would be somehow used as a queue and >> the position p0 would be the first byte of the communication. After >> having enough bytes to process a message, the position would be moved >> to position p1. Then we can expect that the buffer release the byte >> buffer(s) containing the bytes in the range between p0 and p1. Then it >> becomes a bit complicated to define the behaviour of position(int) >> when a call to position(p0) is done. > We just need to implement the slice() method in the IoBuffer to offer > the kind of features you expect. > > > -- > Regards, > Cordialement, > Emmanuel Lécharny > www.iktek.com >
