Is the Azure provider termed too broadly?

[smudge202]

For one reason or another, there are multiple Service Bus' available on Azure. The full blown Service Bus, and the one that serves as an extension of the storage API.

Event Hubs might too be useful, and any number of future technologies could make good candidates.

As such, is the Azure term being used too broadly in the features/azure branch?

[herecydev]

I think there are 3 candidates, Queues, Topics and Event hubs. My plan was to get the infrastructure in a place such that the majority of concepts (observables, serialization, error handling, logging) can be reused and it's just the client that will be swapped out depending on type of message. So I fully expect to implement more azure technologies, it's definitely going to happen.

[smudge202]

I think the "Queues" candidate you've specified is actually duplicated in Azure.

See these links:

• Azure Service Bus which has Queues and Topics
• Azure Storage Queue which also has queues.

These two are completely independent services, namespaces, and NuGet packages.

[herecydev]

Yer, I've seen these before. I'm not sure how many people use the storage queue, I always found the lack of deadlettering and push based messaging a nonstarter for the services I build. With that said, I'm keen to see if people want it and should easily be able to support it.

Perhaps changing the Azure into AzureServiceBus will clarify things?

[smudge202]

The naming change would work for me.

You may find more people than you realise using the Storage variant, because the NuGet packages for it were best at keeping up with dnx. Not checked since netcore.

[herecydev]

Yep it support NETStandard 1.6, the API is reasonably similar. Just need to implement the message pump for the observers and deal with some deadletter logic.