Utility class supporting dynamic topics using topic templates

[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 seen several failures indicating that topic parsing/generation is generally quite error-prone.

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. See the unit tests for more advanced usage, like routing and canonical prefix derivation.

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".

The unit tests did not run so far due to technicalties, but the code works in the internal codebase. I made some effort to align it to MqttNet conventions (as I perceive them). To proceed, I mainly would like to know if such an addition is considered a good fit for MqttNet at all.

[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?