Codec framework being ported to the new API - please review

["이희승 (Trustin Lee)"]

Hi folks,

I started to retrofit the codec framework with the new API at 'next-api'
branch, and it seems to work as expected so far. Please feel free to
review it and let me know what you think:

- http://j.mp/JvGUwx

Notable changes are:

- FrameDecoder is now StreamToMessageDecoder
- Codecs are type-safe
- Because the new API has two different types of buffers
(message buffer and byte buffer aka stream), there are
6 combinations of abstract codecs:
- MessageToMessageDecoder (replaces OneToOneDecoder)
- MessageToMessageEncoder (replaces OneToOneEncoder)
- StreamToMessageDecoder (replaces FrameDecoder)
- MessageToStreamEncoder
- StreamToStreamEncoder
- StreamToStreamDecoder

You will find how these abstract codecs are used at:

- All decoders and length prependers at the codec package
- All codecs in base64, bytes, compression, protobuf

Typical pipeline that encodes and decodes a string with its length
header would look like:

1) LengthFieldBasedFrameDecoder decodes stream into ChannelBuffer
2) StringDecoder decodes ChannelBuffer into String
3) LengthFieldPrepender encodes ChannelBuffer into stream
4) StringEncoder encodes String into ChannelBuffer

To add ZLIB compression:

-2) ZlibDecoder decodes stream into stream
-1) ZlibEncoder encodes stream into stream
1) LengthFieldBasedFrameDecoder decodes stream into ChannelBuffer
2) StringDecoder decodes ChannelBuffer into String
3) LengthFieldPrepender encodes ChannelBuffer into stream
4) StringEncoder encodes String into ChannelBuffer

If a user cares more about performance, he or she can write a new codec
that combined 1 and 2 (or 3 and 4) to reduce memory copy dramatically,
which was not possible in Netty 3.

I'll ping you guys again if a major change is made in the codec
framework. So far, it looks pretty solid in my opinion.

Cheers,
T

--
https://twitter.com/trustin
https://twitter.com/trustin_ko
https://twitter.com/netty_project

[Trustin Lee]

If you didn't have a chance to read my previous announcement about the next API, please read it here:

  https://groups.google.com/d/topic/netty/PFhK9oFRpvA/discussion

Cheers,
T

[Daniel Bimschas]

Hi Trustin,

from a first look the new API looks really great! I think it is a big step forward :-)

Some time ago there was a proposal (of you?) on the mailing list that had the idea that people would be able to use the buffer/codec/transport frameworks independently. Looking at the POM files it looks like this will be possible for the buffer framework as it only depends on netty-common which itself only optionally depends on logging frameworks. The codec module depends on transport. Is there are reason for this? Wouldn't it be possible to just have it depend on the buffer framework? Or is this work in progress?

Best,
Daniel

--
Daniel Bimschas, M.Sc.


UNIVERSITÄT ZU LÜBECK
INSTITUT FÜR TELEMATIK

Ratzeburger Allee 160
23538 Lübeck

Tel +49 451 500 5387
Fax +49 451 500 5382
bims...@itm.uni-luebeck.de

http://www.itm.uni-luebeck.de/users/bimschas

[Norman Maurer]

Hi Daniel,

it needs to depend on transport as it use
Channel/ChannelHandlerContext etc which resist in this module.

Bye,
Norman


2012/5/22 Daniel Bimschas <bims...@itm.uni-luebeck.de>:

["이희승 (Trustin Lee)"]

Hi Daniel,

I'm still experimenting with that idea because some user codecs
interact with their channels. You can always use the codec embedder
even if my idea does not get implemented.

Thanks,
T