Taras Voinarovskyi

Hi, I think v1 will come out after we cover all the spec for AMQP and have it run for at least a few month. Something like that. Or did...

Must probably be fixed based on #56

I don't really want to break the API by making publish a coroutine. How about the publish method will return an object, that can be asked about published message state?...

Basically it relates to both #62 and #56: - We don't check, that the connection is alive at publish calls - We don't wait for socket flush after publish calls

Hello again The 4 cases above don't cover my last proposal, so let me describe it here in the same manner as the above: ### 5. We leave `consume` as...

Now in another comment I will describe why do I care so much about it. I tried to implement proposal 2: [this commit](https://github.com/TarasLevelUp/asynqp/commit/a67cdb6f67505e393dfca870fb11dbc3b8378bb3) Code is quite simple, but I have...

If we do make 'create_consumer', you understand, that it will return 1 object, not 2. So cancelation will be as in proposal 5.

> It can just return 2 objects. > > cancellation_token, consumer = yield from queue.create_consumer(...) Why do you want `create_consumer` to be built on top of `consume`, it's ugly to...

Made some progress on the issue in [my branch](https://github.com/TarasLevelUp/asynqp/commit/6ed2a04acbeeb73d968c0d4e95068c3bab3d6771#diff-9721c3d151f1390e070a4e59a1659be1L331) , and now I can see another reason to have a separate API for QueuedConsumer: The logic for `no_ack=True` and `no_ack=False`...

In a separate branch I created the 5-th proposal implementation with examples for [Python3.4](https://github.com/TarasLevelUp/asynqp/blob/QueuedConsumer/doc/examples/consume_with_reconnect.py) and [Python3.5](https://github.com/TarasLevelUp/asynqp/blob/QueuedConsumer/doc/examples/consume_with_reconnect_35.py) A note on Python3.5 implementation: - Wrapped the `queued_consumer` in an async context manger....