Re: [boost] [async-mqtt5] Review questions

Hi Seth,

On 21.10.2024., at 00:06, Seth via Boost wrote:

On Sun, Oct 20, 2024, at 11:09 PM, Vinnie Falco via Boost wrote:

...

On Sun, Oct 20, 2024 at 1:31 PM Ivica Siladic wrote:

...

TlsContext is indeed not a concept

I think that the treatment of TlsContext in the public API doesn't rise to the same level of quality as the rest of the library. I'm not sure what the best way to improve it is, though.

When I read that, I was already thinking that there could be a factory for (tls) streams. Many dynamic IO frameworks (in other languages) seem to have this approach, I think I remember it from my Java past and even the Curl API seemed to have multiple callbacks to customize e.g. socket creation and configuration.

Of course, this type of customization can be modeled as a "strategy mixin" in the good old Modern C++ spirit. The principle remains the same.

There are several ways to implement a factory-like approach. One option is to use a callback to create the stream. However, since the stream type cannot be type-erased, this callback would need to be a template function. This means the user would have to provide a template specialization to create the stream. During the stream creation, the user would also need access to the corresponding SSL context, which could lead to the use of a global variable or a Meyers-like singleton—neither of which is ideal. Another option is to use a template class, such as TlsStreamFactory, and then templatize the mqtt_client class with this factory. This approach would allow the creation of a well-defined concept (i.e., prescribing the required interface). It is arguably cleaner and easier to understand, but it would require more effort from the user compared to the current TlsContext-template approach. Honestly, I’m not sure which approach is better.

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Thanks, Ivica Siladic