MQTTnet
MQTTnet copied to clipboard
dotnet
Retain the `IMqttRetainedMessagesManager` interface in version 4?
Describe the feature request
It looks like the upcoming version 4 (referring to branch feature/Reason_Code_In_Subscription_Interceptor) no longer exposes the IMqttRetainedMessagesManager interface as an extension point. Using the IMqttServerStorage interface instead is fairly limiting and may not be the best option when dealing with physical storage (see also comments in #1206). So far the IMqttRetainedMessagesManager could be used to inject one's own retained message manager, which means one is not limited by IMqttServerStorage .
Which project is your feature request related to?
- Server
Describe the solution you'd like
It would be good to keep the IMqttRetainedMessagesManager extension point available in version 4.
Describe alternatives you've considered
Alternatively the IMqttServerStorage could be modified to contain the methods that were previously in the IMqttRetainedMessagesManager interface.
I have noticed that the new philosophy is to use the event handler based approach on MqttServer; this works fine for me. Closing.
Does the new handler-based approach in IMqttServerStorage allows for completely custom retain logics? Like storing the retained messages on Redis and retrieving them on the fly, like we're doing today using the old interface?
@fogzot I think you can do the same as with IMqttRetainedMessagesManager. Instead of
.WithRetainedMessagesManager(...)
you hook up events like so:
server.RetainedMessageChangedAsync += Server_RetainedMessageChangedAsync;
server.LoadingRetainedMessageAsync += Server_LoadingRetainedMessageAsync;
server.RetainedMessagesClearedAsync += Server_RetainedMessagesClearedAsync;
IMHO, this is a regression because it always keep a copy of all retained messages in memory while the interface could have been improved to allow for a completely different storage.
@logicaloud can you please reopen this so that I don't have to create a new one?
The interface is more concise and convenient for extension developers, I agree, but whether retained message payloads are held in memory or for how long, etc., is dictated by the internal handling of retained messages, not by the event vs interface exposure. It would be fairly easy to re-introduce the interface and hookup events internally to the interface I think. I'll reopen and maybe @chkr1011 can comment.
I will consider adding another event for the version 4.1 which will allow to "provide" all affected retained messages to the server. But then the library user must take care of filtering these messages properly (performance and memory efficient).
I will consider adding another event for the version 4.1 which will allow to "provide" all affected retained messages to the server. But then the library user must take care of filtering these messages properly (performance and memory efficient).
Currently it is still not implemented or did I miss it?
