- Channel now creates a ChannelPipeline by itself
I find no reason to allow a user to use one's own pipeline
implementation since I saw nobody does except for the cases where a
user wants to add a user attribute to a channel, which is now covered
by AttributeMap.
- Removed ChannelEvent and its subtypes because they are replaced by
direct method invocation.
- Replaced ChannelSink with Channel.unsafe()
- Various getter renaming (e.g. Channel.getId() -> Channel.id())
- Added ChannelHandlerInvoker interface
- Implemented AbstractChannel and AbstractServerChannel
- Some other changes I don't remember
- Add EventLoopException to wrap the exceptions while an event loop does
something
- Make EventLoop.register() return EventLoop so that the caller knows
the actual EventLoop that will handle the Channel even if the caller
called register() from MultithreadEventLoop
- Rename ChannelReader to ChannelInboundHandler
- Rename ChannelWriter to ChannelOutboundHandler
- Introduce ChannelBufferHolder instead of adding the common super type
of message buffers and byte buffers
- This is more type-safe and natural.
- Remove the notification methods for buffer closure (might add back
later when revisiting half-closed connection support)
- Merged LifeCycleAwareChannelHandler into ChannelHandler
- Replaced ChannelUpstreamHandler and ChannelDownstreamHandler with
ChannelReader and ChannelWriter
- These two new interfaces are much more type-safe than its ancestor.
- Simplified channel state model as described in #68
- Handler creates send/receive buffer.
- Previously, Netty created them, but it led to more memory copies and
inflexibility. I'm going to allow a handler to create a bounded
queue for example.
- It currently uses Queue<T> but I'll define a new interface and make
ChannelBuffer implement it (e.g. Queue<Byte>)
- Introduced AttributeMap which replaces attachments in Channel and
ChannelHandlerContext and ChannelLocal
