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/
signature.asc
Description: OpenPGP digital signature
