MQTT simple API

[koniarik]

Hi,

I may be rude now, so sorry in advance.

Could we rethink mqtt api as it is now? Unfortunately as many other libraries I see that mqtt.simple tries to make it's own 'socket'. But, does it really makes sense? It's network communication protocol, making the connection and getting a way to write/receive data should not be it's business. It's business is to make data with some sense from incoming bytes and send sensible bytes.

Problems:

• you will start to bloat protocol api with socket/ssl options
  • ssl header "ssl.wrap_socket(sock, keyfile=None, certfile=None, server_side=False, cert_reqs=CERT_NONE, ca_certs=None)" got pretty range of args to be fully supported :)
• you practically blocked people from using something else then socket, while not many people could think about it, but with protocol you could still send it's data over bluetooth/i2c/spi/uart.

Solution:

• mqtt.simple should be able to work in two modes:
  • either make simple socket
  • connect() is relevant
  • or get 'socket' api friendly object
  • connect() is not relevant, we want only initialize the mqtt protocol connection

This way I can prepare connection in any way I want on anything I want, and just pass proper object to mqtt "hi, here you got com object, use as you want".

So, what you think?

P.S: I am in state that I need to pass cert arguments to ssl, so I should be able to come with patch for this eventually

[pfalcon]

Could we rethink mqtt api as it is now?

Generally, no. There was RFC for MQTT implementation: https://github.com/micropython/micropython/issues/2055, people who were interested participated in the discussion and affected how it was implemented. But it's implemented now.

Unfortunately as many other libraries I see that mqtt.simple tries to make it's own 'socket'.

I'm big fun of dependency injection pattern myself, but others don't have to (be fan of it or even understand it), see for example https://github.com/micropython/micropython/pull/2285#issuecomment-238157932 . Also, it has limits on its use to. For MQTT support, there was (implicit) requirement that it was easy to use, and there was "robustness" support (also easy to use), so socket is the part of the controlled state.

you will start to bloat protocol api with socket/ssl options

Addressed by 98c6fb9024afd94f0bee3f09662e50387c623b49.

So, what you think?

You can always write your MQTT implementation (and popularize/support it).

[koniarik]

I see, missed that, sorry than...

ssl_params seems that as good enough solution

2016-08-24 0:23 GMT+02:00 Paul Sokolovsky notifications@github.com:

Could we rethink mqtt api as it is now?

Generally, no. There was RFC for MQTT implementation: micropython/micropython#2055 https://github.com/micropython/micropython/issues/2055, people who were interested participated in the discussion and affected how it was implemented. But it's implemented now.

Unfortunately as many other libraries I see that mqtt.simple tries to make it's own 'socket'.

I'm big fun of dependency injection pattern myself, but others don't have to (be fan of it or even understand it), see for example micropython/micropython#2285 (comment) https://github.com/micropython/micropython/pull/2285#issuecomment-238157932 . Also, it has limits on its use to. For MQTT support, there was (implicit) requirement that it was easy to use, and there was "robustness" support (also easy to use), so socket is the part of the controlled state.

you will start to bloat protocol api with socket/ssl options

Addressed by 98c6fb9 https://github.com/micropython/micropython-lib/commit/98c6fb9024afd94f0bee3f09662e50387c623b49 .

So, what you think?

You can always write your MQTT implementation (and popularize/support it).

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/micropython/micropython-lib/issues/93#issuecomment-241899263, or mute the thread https://github.com/notifications/unsubscribe-auth/AFlRAjZpHGUxOXSdFlYlESvU_1XHK7pXks5qi3LEgaJpZM4JptdL .

Jan Koniarik squirrelcze@gmail.com