async/await API

[michaelklishin]

Originally this issue was about enabling of message publishing with a natural future ("awaitable" in the .NET world) API.

After some discussions with the .NET community, it makes more sense for us to switch to async/await entirely. This is a major change. The users who cannot upgrade in the meantime will be able to use 3.6.x versions with future RabbitMQ releases.

The decision is to develop a completely new client oriented towards async/await, although #307 introduce it in a place where it makes most sense and can be done with relatively few breaking changes.

[ngbrown]

I think moving to an async API with Task returns is a good idea in general, the question is how is this going to be managed?

I've seen .NET libraries (e.g. MongoDB client) that go async do it in a way that splits the entire API into an old/new set of namespaces if not actual libraries (that need to be separately pulled from nuget). Generally, the non-async methods become wrappers for the async ones, thus the split.

[michaelklishin]

That's what we have in mind.

[rasmus]

+1

[danielmarbach]

Could I help out somehow?

[michaelklishin]

@danielmarbach a good way to start would be to look into how much effort it would be to have an async/await-oriented version of IModel and 2 implementations (recovery-aware and "regular" one). Then we can go on to implementing it. All development happens on GitHub in the open.

[danielmarbach]

Should I do a spike then to see what is affected?

Am 08.01.2016 um 08:46 schrieb Michael Klishin notifications@github.com:

@danielmarbach a good way to start would be to look into how much effort it would be to have an async/await-oriented version of IModel and 2 implementations (recovery-aware and "regular" one). Then we can go on to implementing it. All development happens on GitHub in the open.

—
Reply to this email directly or view it on GitHub.

[michaelklishin]

@danielmarbach feel free. Thank you very much for your time!

[danielmarbach]

I do this the all-in way. No more sync APIs.

Am 08.01.2016 um 11:26 schrieb Michael Klishin notifications@github.com:

@danielmarbach feel free. Thank you very much for your time!

—
Reply to this email directly or view it on GitHub.

[michaelklishin]

Sorry but we cannot remove existing APIs. A ton of code in the field depends on them. We can build them on top of async/await but even then I suspect there is no way around having two channel (IModel) APIs.

[danielmarbach]

Fine with me if you know what the consequences of this decision are:

Having two completely sep. code paths and therefore the potential of fixing one path and forgetting the other one

Am 08.01.2016 um 11:32 schrieb Michael Klishin notifications@github.com:

Sorry but we cannot remove existing APIs. A ton of code in the field depends on them. We can build them on top of async/await but even then I suspect there is no way around having two channel (IModel) APIs.

—
Reply to this email directly or view it on GitHub.

[danielmarbach]

See for example what we did

http://particular.net/blog/async-await-its-time

Am 08.01.2016 um 11:32 schrieb Michael Klishin notifications@github.com:

Sorry but we cannot remove existing APIs. A ton of code in the field depends on them. We can build them on top of async/await but even then I suspect there is no way around having two channel (IModel) APIs.

—
Reply to this email directly or view it on GitHub.

[michaelklishin]

@danielmarbach thank you for your perspective. RabbitMQ (and this client) is almost 9 years old. We understand the consequences of major changes, in client libraries and elsewhere. We also know very well what happens when you break things.

.NET client has two versions ("regular" and WinRT) that share effectively all unit tests, for example. So far so good.

[danielmarbach]

Didn't want to imply that you guys are clueless or anything. Sorry if I sounded like a jerk.

I was talking about the implications on the team maintaining the lib not the breaking changes per se

Am 08.01.2016 um 11:41 schrieb Michael Klishin notifications@github.com:

@danielmarbach thank you for your perspective. RabbitMQ (and this client) is almost 9 years old. We understand the consequences of major changes, in client libraries and elsewhere. We also know very well what happens when you break things.

.NET client has two versions ("regular" and WinRT) that share effectively all unit tests, for example. So far so good.

—
Reply to this email directly or view it on GitHub.