IoBuffer refactoring take 2

[이희승 (Trustin Lee) <t...@gmail.com>]

The following is my summarization about the IoBuffer issue.  Please let
me know if I missed something.  As you know, it was a very long thread. :)

Consensus so far:
=================
IoBuffer is too fat and complicated - we need a new envelope (I think
'envelope' is a better term because TransportMetadata already using that
term.)

Requests:
=========
1) Provide a better way to deal with packet fragmentation & assembly
because:
   1a) Reallocation cost matters
   1b) Once packet is correctly reassembled, it can be decoded very
easily using DataInputStream or any other means.

2) Simplify the current buffer API because the current buffer API is too
fat and difficult for users and developers to extend, implement and
maintain it.

3) We still need a convenient way to encode a message while making the
buffer API simpler (see 2).  Auto-expansion needs improvement in terms
of reallocation (see 1a) and security (too big buffer).

4) Maintain compatibility with existing JDK classes such as
Input/OutputStream and ByteBuffer (if not going to use ByteBuffer as an
envelope.)

My reasoning so far:
====================
1) The request 1b, 3 (partially) and 4 are not an issue - we already
provide compatibility layer for Input/OutputStream and ByteBuffer and we
can just limit the maximum buffer size to fix the possible security issue.
2) To resolve the request 1a and 3, we need a composite buffer.
3) The composite buffer needs to be a subclass of ByteBuffer so it can
be transparent to users even after packet reassembly.
4) However, we can't extend NIO ByteBuffer at all.
5) Then, we need a new type to provide a composite buffer to resolve the
request 1a.
6) However, introducing a new type might interfere with the request 2.

Next step:
==========
So... what would be the next step?  What I can think of right now is to:

1) Make composite buffer which does not extend ByteBuffer,
2) or be very careful to introduce a new type?

My preference is to introduce a new type carefully, but YMMV.  Any
inspiration would be appreciated.

Thanks,
-- 
Trustin Lee - Principal Software Engineer, JBoss, Red Hat
--
what we call human nature is actually human habit
--
http://gleamynode.net/