Provide predicates for connection and channel status

[michaelklishin]

Originally filed as #97. Java, .NET, Ruby (Bunny) all provide such predicates.

[camelpunch]

I dodged this originally because the client has an async API. If all other operations are placed on a client-side queue, when would an application want to know if the client is connected - right now or after everything in the queue has been tried?

It might be a confusing experience for the developer if these concepts aren't expressed in the API. We could have both an async (with a block) and immediate predicate, perhaps?

[michaelklishin]

One reason to check connection and channel state would be when you need to know if it's safe to [re-]publish a group of messages, e.g. to sync local mobile app state with that of the server. Note that it's not used to know when a connection succeeded.

In other clients it's a point-in-time predicate. I think this is what #97 is asking about.

[camelpunch]

In that case it feels to me like you'd still want to use a block, because you'd probably want to avoid trying to re-send the messages if, by the time the local queue had been processed, your connection had dropped again.

Another thing to consider is the high likelihood of being in a connection recovery cycle on mobile. During recovery, none of these conditions are sufficient for knowing that it's safe to re-send:

• the socket is connected
• the AMQP connection is established
• the channel is declared

You'd probably want to know that the entire topology had been redeclared before re-sending. Again, this doesn't seem to be covered in other clients, so maybe it isn't actually needed as much as I'm thinking.

[michaelklishin]

I'm still convinced that having a predicate for channels is a good idea and we will get requests for this again and again.

[camelpunch]

I agree - but we should be careful about how it's implemented, or just how it's named, to avoid false / misleading return values.