Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [paho-dev] API Suggestion on the Embedded Paho MQTT Client

I think the idea was to have a user defined struct provided as part of the subscription passed back into the callback. Rather than just the payload which is provided by the broker. Could be useful.


On Nov 8, 2014 3:03 AM, "Ian Craggs" <icraggs@xxxxxxxxxxxxxxxxxxxxxxx> wrote:

I'm very happy that you are finding the library useful.

I'm not sure why the type of the MessageData parameter passed into the messageHandler should force you to use global variables.  There are two parts to the data received by the library from MQTT 1) the MQTT specific parts, and 2) the user data.   The user data is part of the Message structure:

struct Message
    enum QoS qos;
    bool retained;
    bool dup;
    unsigned short id;
    void *payload;
    size_t payloadlen;

 and is called "payload".  It's type is a void *, so allowing you to cast it to any type you want.  There is no type associated with any payload in an MQTT message, so if you need one you could add that information to the MQTT topic, or to the MQTT payload, when you publish the message.

Ian Craggs

MQTT Open Source Projects
IBM United Kingdom
Hursley Park
Tel: +44 1962 818553

From:    "Xuejie \"Rafael\" Xiao" <xxuejie@xxxxxxxxx>
To:    Ian Craggs/UK/IBM@IBMGB
Date:    11/07/2014 02:00 PM
Subject:    API Suggestion on the Embedded Paho MQTT Client

Hi there,

I was working on an MQTT-related product and found your Embedded Paho MQTT Client at here. First of all, allow me to say: thank you for creating such an awesome library! Really suitable for what I'm working now and saved a lot of development.

However, I do have one suggestion on the API, right now, the message handler used in subscribe request is only passed the message data:

typedef void (*messageHandler)(MessageData*);

My question is, is there any chance that we can change this API to allow for user-specific data, like a void*? Right now this forces us to use global variables to handle data, which may bring problems if we want to create multiple MQTT connections.

I know that this use case is very rare, I know that the API may be stable for a while, and you might not want to change it easily. However, I still wanna throw out my ideas in case you have exactly the same thing in mind. And I can always start crafting this if you feel like this is a good idea but don't have time for this.

Anyway, let me know what you think of this, and thanks again for bringing this awesome library!

Best Regards,

Xuejie "Rafael" Xiao

Ian Craggs
icraggs@xxxxxxxxxx                 IBM United Kingdom
Paho Project Lead; Committer on Mosquitto

paho-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Back to the top