gRPC deframer complexity

Is it only myself who finds ArmeriaMessageDeframer more complex than necessary? I think we can simplify it in the long term by writing a building block like the following:

Write a Reactive Streams Processor which decodes a stream of HttpObjects into another stream. It is different from FilteredStreamMessage in that it allows decoding M HttpObjects into N objects. This will provide some extension point like Netty’s ByteToMessageDecoder does.

On top of this building block, we could rewrite ArmeriaDeframer with much less state management.

It may be possible to do something similar for ArmeriaMessageFramer, but I didn’t think much about it yet.

[trustin]

We also need to try to reuse the HttpData in an input stream when producing an output stream to reduce unnecessary memory copies. For example, we could forward the input HttpData instance as it is when it is a partial content without any other stuff like boundaries and length headers. Could use WITH_POOLED_OBJECTS when necessary as well.

[jrhee17]

I know you’re already working on multipart stuff, so I’ll look for another issue. I’ll try to pop in for reviews instead 😄