Marnie McCormack wrote:
I think what you are proposing sounds good. Excuse my C++ ignorance, but is there any way to deprecate SetTcpNoDelay i.e. keep it in there but indicate that new client apps should not use it ? I ask as I know of at least one application already using this method in prod.
The API for the c++ client has changed significantly between M2 and trunk. We do have an implementation of the old interface mapped to the new one, but that was mainly used for transitioning and my intention was always to remove it.
I suspect there would be several issues in upgrading an application from the M2 c++ client to the trunk c++ client (and setting tcp-nodelay would be the least of them!). It is certainly possible to minimise that by providing a legacy 'adapter' of some sort. As always this is going to be a matter of balancing the available effort with the demand from users.
As with all feature requests and feedback, I'd encourage users who are planning such a transition and are keen to minimise the impact make their voices heard and we can figure out the best path forward.
Ultimately the aim is to have higher level abstractions that would be entirely independent of the protocol version. Applications could program to those abstractions and not worry about the details of the mapping underneath. At present we have the core API in place on trunk that exposes all the AMQP commands and concepts fairly directly. We also have the beginnings of some more abstracted utilities. So its a great time to try it all out and influence the evolution!
(One caveat to that: there will be a degree of change as we transition from the 0-10 preview to the 0-10 final version; that should be completed quite soon I expect).
