i hate channel handlers.
not because they stole my bike or insulted my cat, but because i have no clue how to use them aside from what i can deduce from NIO’s incredibly sparse examples.
they are untyped, crash with cryptic messages when you connect them in the wrong order, and the diagram in the documentation doesn’t match the three-layer formation that the NIO developers say they take in reality.
so i (and i don’t know how many others) have simply resigned to only writing “final” channel handlers, one that only implement
channelRead and forward incoming requests to something that is not part of the channel pipeline.
but now, i have been advised to implement “intermediate” channel handlers that go in the fan-outs between the three-layer pipeline:
a channel handler that lives in the root pipeline and “reads” smaller pipelines (what?) and… well… i don’t know what it does with the smaller pipelines after it has read them. (forward them to the next handler? drop them? what is the pattern here?) there are no type hints. everything is
a channel handler that lives in the smaller pipelines, and well… same deal.
how do you implement a channel handler that goes in the middle of a pipeline? and can we update the docs with an explanation of how the “hierarchical” pipelines work? the existing documentation is not exactly helpful in this respect.
For example, a typical server will have the following handlers in each channel’s pipeline, but your mileage may vary depending on the complexity and characteristics of the protocol and business logic:
Protocol Decoder - translates binary data (e.g. ByteBuffer) into a struct / class
Protocol Encoder - translates a struct / class into binary data (e.g. ByteBuffer)
Business Logic Handler - performs the actual business logic (e.g. database access)