Proposal: Incompatible API changes

[Noa Resare]

dano,

If we're doing incompatible API changes with the new ZMTP/2.0 stuff, I have some other changes I would like to see as well:

1) Having a ZMTPContext being used both as a method for communicating parameters to your ZMTPFraming{Encoder|Decoder} instances and as a method for extracting the remote peer identity makes it a bit conceptually tricky. Especially since the remote peer identity value only can be read after it has been extracted from the handshake process.

I propose that we make the HandshakeListener part of the external API instead, so that consumers interested parameters of some session can register a listener and get a notification holding that information once it's available.

2) Wrapping each bean style value object (ZMTPMessage) in a container (ZMTPIncomingMessage) that combines a value object with a live object (ZMTPSession) reference that can be used to send data to the other peer (getChannel().write()) seems like mixing some different types of data, as well as introducing unneeded object creation and wrapping in the hot execution path. ChannelUpstreamHandler instances that receives ZMTPIncomingMessage instances currently. I think the natural thing would be to have the ZMTPFrameDecoder emit ZMTPMessage instances instead.

/n

--

Spotify Free Software coordinator, strategist and possibly evangelist. I/O Tribe.