You are reading a single comment by @Rovale and its replies. Click here to read the full conversation.
  • @Rovale since you're "building" the module, maybe you'd be able to generate two modules by excluding some features, a basic one and a full-featured one. Basic is pretty much publish and subscribe, doesn't do anything extra like Last Will, full feature does everything.

  • Hi, my purpose is to create an MQTT client which is reliable enough that I would dare to control my heating with it, for instance. It should:

    • Always try to stay connected. It should reconnect if the connection is lost.
    • Be able to publish and subscribe at QoS 1 level (actually I think it's impossibly to truly support publishing at QoS 1).
    • Be able to publish retained messages to allow other devices which just connect to get up to date with the last status messages.
    • Have a Last Will Testament to let other devices know it it is online or offline.

    On the other hand it does not need to:

    • Support QoS 2.
    • Unsubscribe.
    • Disconnect.
    • Get user friendly error messages.
    • Have a rich monkey proof API with too many overloads.

    If size is a serious issue then it can be interesting to consider multiple variants of MQTT client. What would your typical use case be and what features you think it would require?

    I am still very new on the Espruino field so if somebody can give me some guidance on measuring size and memory usage and on how to keep things small, then that would be helpful.

    By the way, yesterday I implemented the Last Will and Testament feature. It did not take that much new code :-)

About

Avatar for Rovale @Rovale started