Last night, we purely focused on sequential scanning of incoming data regarding handling a composite buffer. I kept thinking about our decision not to introduce any new type while I sleep, and I found a few critical issues with it:
* As Rich pointed out, random-accessing the composite buffer has too
much overhead with finding a right ByteBuffer when just an index and
Iterable<ByteBuffer> are provided. More information (e.g. cache or
index tree) should be provided for faster access.
* Even if what user is doing is just sequential scanning of incoming
data, it's so much pain if a user happens to access data which spans
over more than one ByteBuffer. For example, imagine the first buffer
contains 3 bytes and you want to read a long integer.
So.. I think we should introduce a new type at least for composite
buffer, even if we are going to ditch IoBuffer. Probably something like
this?
public interface CompositeByteBuffer extends Iterable<ByteBuffer> {
// These two are optional and can throw an exception when
// this is read only.
CompositeByteBuffer prepend(ByteBuffer bb);
CompositeByteBuffer append (ByteBuffer bb);
// All ByteBuffer methods here; make sure to provide the same
// experience for better learning curve.
int getInt(int index);
int getInt();
...
CompositeByteBuffer asReadOnly();
CompositeByteBuffer duplicate();
...
}
We might not even need to make it an interface. The implementation
shouldn't overlap much with that of NIO ByteBuffer because most methods
will be implemented in three steps:
1) Find a proper ByteBuffer
2) Forward the call to the found ByteBuffer
3) If the call should be span over more than one ByteBuffer, handle it.
Why didn't we discuss about this issue? I don't know, but I think this
is quite an important issue. :)
Therefore, I'd propose to use a dedicated type instead of
Iterable<ByteBuffer>. WDYT?
"이희승 (Trustin Lee) <[EMAIL PROTECTED]>" wrote:
> After long long IRC conversation with Emmanuel Lecharny, Julien
> Vermillard and David M. Lloyd. We seem to have reached to the following
> temporary consensus:
>
> 1) Ditch IoBuffer and use ByteBuffer directly.
> 2) Provide all convenience methods IoBuffer provide as static methods so
> they can be static-imported.
> 3) Modify our filter implementations to understand ByteBuffer and
> Iterable<ByteBuffer>.
> 4) Update the IoFilter tutorial to inform users about this change.
>
> This change means we decided not to create a new type to support
> composite buffer. Iterable<ByteBuffer> seems to be enough.
>
> This change will take place in a new branch and its review will be
> requested before merger.
>
> Another issue to think about is how we can implement auto-expansion.
> Many users find it very useful when they construct a variable length
> message. My idea right now is to provide a builder class which builds
> an Iterable<ByteBuffer> or ByteBuffer depending on user preference.
> Same preference property should be provided by the protocol codec
> framework for those who still wants a single ByteBuffer. I will also
> explore this in the branch.
>
> Any more feed back before I proceed?
>
> Cheers,
--
Trustin Lee - Principal Software Engineer, JBoss, Red Hat
--
what we call human nature is actually human habit
--
http://gleamynode.net/
signature.asc
Description: OpenPGP digital signature
