[rabbitmq-discuss] Fw: high availability solutions?

[Michael Klishin]

Matthew Sackman escribió:
> We would encourage all 3rd party clients to work to support the
> extensions to AMQP 0-9-1 that we add. That does not mean that we
> recommend you remove functionality that we remove - you can certainly
> implement a superset of the functionality. But normally when we add and
> remove features, it's because there is some fundamental deficiency that
> needs to be addressed and so it's obviously helpful if 3rd party clients
> are aware of that.
Matthew,

I trust the RabbitMQ team judgement and agree that tx.* class has relatively few use cases
with Publisher Confirms. amqp gem also supports publisher confirms in 0.8.x series, our test suite covers them
and I am going to document that extension in detail with examples very soon.

That said, as a client library maintainer, I have a number of concerns:

* Should I explicitly discourage people from using tx.* class?
* How do I justify even more protocol fragmentation to library users?
* What do I do with my test suite that covers tx.* operations? I can add conditions that check for RabbitMQ versions
but that makes me think of Internet Explorer 6 and you can imagine what kind of thought that is.

I am not too worried about this. I see just one case my when applications could use tx.* and they currently don't.

However, I want amqp gem to have excellent documentation that also helps library users understand when to use what features
and why. The prospect of tx.* removal from that standpoint is a problem for me. We already have to explain people what AMQP 0.8 to
0.9.1 move means and why they cannot use stock Ubuntu packages. Adding one more note that "oh, and if you happen to use transactions,
please use RabbitMQ server < 2.6.0" is possible but I can imagine it won't reassure readers in RabbitMQ stability and maturity.

So, what are the RabbitMQ team recommendations for library maintainers? 
MK

http://github.com/michaelklishin
http://twitter.com/michaelklishin