| Re: [paho-dev] API Suggestion on the Embedded Paho MQTT Client |
Hi Rafael,
ah, now I understand. That makes sense, yes.
As I started writing this client on mbed, I am using the FP class which aims to make it easy to pass in method parameters as well as global functions. The limitation of this class is that it can only deal with one parameter, which would mean adding a field to the MessageData structure:
struct MessageData { MessageData(MQTTString &aTopicName, struct Message &aMessage) : message(aMessage), topicName(aTopicName) { } struct Message &message; MQTTString &topicName; void *context; };
and a parameter to the subscribe method:
int subscribe(const char* topicFilter, enum QoS qos, messageHandler mh, void* context = NULL);
Oh, from your examples, it seems you're using the C version of this code. The same principle applies. I want to keep both these APIs in exact sync. In fact I'd really like the C version to be generated by script from the C++.
Is there a particular reason you're not using the C++ version?
Ian
On 11/10/2014 05:49 AM, Xuejie "Rafael" Xiao wrote:
Ian:
Thanks for your reply! Agreed that we should talk about this on paho mailing list in case others are also interested.
About the question: yes, I'm aware of the payload part, actually when I said "user-specific data", I was talking about the some context data used in the problem, not used by an end-user. To make this problem more complete, I will also shortly describe our use case here, in case we are using MQTT in a wrong way.
Instead of the normal pub/sub pattern, we are actually using MQTT in a slightly weirder way: in short, we implement a simple RCP on top of MQTT with the following setup:
1. We have a service (also treated as an MQTT client) that listens to certain topics of the broker(foo/+/bar for example).
2. We also have other clients that can send messages(requests) via foo/(client id)/bar channel, in the payload of the message, we include a randomly-generated message ID part.
3. When the service gets the message, it will perform certain actions, and send reply as a message through foo/(client id)/bar_response channel. The reply will also include the corresponding message ID.
4. The client gets the response from foo/(client id)/bar_response.
For this architecture to work, the client will need to subscribe to the response channel before sending the request. In addition, the client should also check if the message ID in the reply matches the message ID in the request part(to see if we have sent such a message). This means we have to maintain a list of currently-sent message IDs in the context data, which is exactly the context data I mentioned above, or "user-specific data" in my original email.
So this is the reason that I think we should add another (void*) as program-specific context data. And I think this should be included in the subscribe API function. In other words, we might want to change this API:
int MQTTSubscribe(Client* c, const char* topicFilter, enum QoS qos, messageHandler messageHandler);
to this one:
int MQTTSubscribe(Client* c, const char* topicFilter, enum QoS qos, messageHandler messageHandler, void* context);
Does this make sense to you? It might also be the case that we are using MQTT in the wrong way. Let me know what you think :)
Thanks a lot!
On Sat, Nov 8, 2014 at 7:03 PM, Ian Craggs <icraggs@xxxxxxxxxx> wrote:
Hi,
I'm very happy that you are finding the library useful. It's good to have these suggestions where everyone can view them, so I'm going to copy your question and my reply to the paho mailing list https://dev.eclipse.org/mailman/listinfo/paho-dev. It would be great if you could ask any follow up questions there.
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.
Thanks!
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
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
--
Best Regards,
Xuejie "Rafael" Xiao
_______________________________________________ paho-dev mailing list paho-dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/paho-dev
-- Ian Craggs icraggs@xxxxxxxxxx IBM United Kingdom Paho Project Lead; Committer on Mosquitto
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/paho-dev