-
Notifications
You must be signed in to change notification settings - Fork 727
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New properties for protected attributes so downstream can depend on them #764
Comments
I think that read properties are fine and will be done. Write properties are an issue to me. What means changing the client_id when you are connected ? Should we disconnect and reconnect with new client_id ? Only wait for next reconnection to use the new ID (which could happen days later) ? |
I've added with write for most properties. Some will only apply on next reconnection (as described in docstring). |
As discussed in the pull request, I'm not convinced it's necessarily the best idea to add setters for all properties, especially when they won't take effect immediately. @skewty (and @frederikaalund from the aiomqtt issue): what would be the use case for setting e.g. a host or port for a client that's already connected? Could one not just create a new client in that case? |
Creating a new client requires, of course, re-binding all the callbacks as well. If all my code knows about is the new host + port to use that becomes an issue. My use case is somewhat complicated because it uses asyncio and paho is a hidden requirement. Downstream developers are reluctant to couple to protected fields (as they should be). Small decisions can have larger impacts due to this. What is likely to happen is other projects just keep their own copy of values that are already in paho. I guess I was hoping paho would make these changes to be a little bit more open for extension (open-closed principle in SOLID) even if it doesn't need the function itself. |
I don't get the use-case for writing host property with aiomqtt. It's API is made such as when the Client (paho-mqtt & aiomqtt) is created, the host is already decided and immutable or did I miss something ? I believe only two options are valid (and prefer the first):
If we don't do that, the following would be nondeterministic:
I think we might be able to write similar case in aiomqtt (we only need to have concurrency between the connection & the It seems much easier to just don't allow writing host, port and keepalive, especially since those 3 value are overwrite by connect() anyway. |
As commented in the PR, I'll disallow changed connection related properties while connected or connecting. It'll only be allowed to change them before first connect/connect_async/reconnect or after disconnect() |
I am hoping the PAHO team would be open to exposing some currently protected attributes as properties so downstream projects can / will couple to them.
Reference: empicano/aiomqtt#191
Example of what is desired:
The text was updated successfully, but these errors were encountered: