Sean Treadway

Without some more concrete examples, it's hard for me to measure whether these interfaces would be along the right boundaries. For example, putting all the notify methods in one interface...

It's easier to add methods to interfaces, than it is to remove them. The complete method list as @michaelklishin proposes does not seem to fit the strengths of the Go...

#389 should be merged before this because it will add a new set of context based methods.

My concern is that every symbol exported must have a reason to support it, and I don't yet see a reason to export the large `type Channel interface`.

> Channel struct just have many responsibilities and you could simply do a lot with it. We are already returning large Channel struct, so returning evenly large interface would not...

I think the smaller interfaces, with an example of how they are composed (like the `AMQPClient` application type above) would be valuable. This sounds like it's a step towards the...

This post also applies some of the SOLID design principles to Go, including Interface Segregation: https://dave.cheney.net/2016/08/20/solid-go-design > Clients should not be forced to depend on methods they do not use....

> If we would like to use main amqp package, then we would need to rename Channel and Connection structs (which we can't because it's breaking change) or change the...

> May I suggest amqp/interfaces instead of amqp/amqpiface? In Go, imported package names are required to be referenced. When using `interfaces` as the package name, the `Channel` interface would be...

I've also been bitten by debugging this error. The error API for connection handshake doesn't easily carry the stage of the handshake along with the reason when using package level...