Utility class supporting topic templates / dynamic topics

[simonthum]

This is essentially some support code to handle dynamic topic subscription, publication and related functonality without falling back to String.Format() and other cumbersome handcrafted magic.

The code has seen a bit of production use and I figured it might be a useful addition to the library. I realize it could well live outside of MqttNet, but OTOH I've had several complaints that topic parsing/generation would be too cumbersome.

The MqttTopicTemplate class processes "topic templates" like A/B/{parameter}/D and provides a fluent interface to operate on the named parameter(s). A bunch of extension methods hook up with related MqttNet APIs, resulting in code like

var topicTemplate = new MqttTopicTemplate("A/v1/{param}/F");
var filter = topicTemplate.BuildFilter()
    .WithAtLeastOnceQoS()
    .WithNoLocal()
    .Build();  // subscribes A/v1/+/F

var msg = new MqttApplicationMessageBuilder()
    .WithTopicTemplate(
        topicTemplate.WithParameter("param", "foo"))
    .Build();  // A/v1/foo/F

Effectively, this enables one to handle subscription and publication from one topic template.

The syntax is simple and fairly common, inside and outside of pub/sub. It is not standardized, but AsyncAPI calls this a "channel address expression".

[simonthum]

@dotnet-policy-service agree [company="medDV GmbH'"]

[simonthum]

@dotnet-policy-service agree company="medDV GmbH"

[simonthum]

@chkr1011 It seems the CI failures require your attention.

[chkr1011]

I like the idea of working with templates but in my opinion it should not be part of the core library. I would rather move it to an extension library like "MQTTnet.Extensions.TopicTemplates".

[simonthum]

You mean alongside Rpc and Managed Client? That sounds fine.

[simonthum]

I'd need to know what can be done about the tests though.

[simonthum]

I have restructured the code for publication as an extension.

I would like to add more tests and examples, but first the build has to work. It seems that the failing security checks are unrelated. Is there anything more I can do but waiting?

[chkr1011]

@simonthum I applied the code style from the team shared settings in Rider and also extended the release notes. If you agree with the changes I will merge the PR

[simonthum]

Hi, sorry I did not use Rider. I am OK with the formatting changes, please go ahead and merge.

One minor thing: You also updated one file in the RPC extension which I did not change (at least not intentionally).

[simonthum]

I should add that unit tests have not yet been run on my side, so they might still contain glitches. I reworked them to be more instructive, but was unable to run them locally. I can probably fix things in a few days if required.

[simonthum]

Hi, thanks for merging!

I installed rider, got unit tests to work and go green 🟢

https://github.com/simonthum/MQTTnet/tree/fix-pr-1932

Should I make another PR or do you prefer to fetch them?