Skip to content
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

add support for mqtt v5 #33

Open
wants to merge 5 commits into
base: master
Choose a base branch
from
Open

add support for mqtt v5 #33

wants to merge 5 commits into from

Conversation

niecore
Copy link

@niecore niecore commented Jan 25, 2022

Fixes #26

I decided to to create separate functions for all v5 functionality because of the following reason:

  • This lib is a wrapper for libmosquitto and they did the same way
  • Some functions have additional functionality besides the props like reason codes or bind addresses

While this PR is open I will check further how testing could be improved and see if the documentation needs additional updates.

int on_unsubscribe;
int on_unsubscribe_v5;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All the callbacks can stay the same right? you can't have v3 and v5 in the same client object, so there's no confusion there.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

libmosquitto will call both callbacks when i.e. mosquitto_connect_callback_set and mosquitto_connect_v5_callback_set have been called before.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is that actually meaningful? a client can only be one protocol at a time, so being able to register two, and getting two callbacks just seems like complexity for nothing

Copy link
Author

@niecore niecore Feb 4, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the idea for the v5 api design of libmosquitto is, that old code can stay unmodified and meanwhile can be extended with v5 functionality by just adding postfixed _v5 functions to your codebase.

Now since Lua is much more flexible than C, because of optional arguments and so on, there could probably also be a method to reach the same goal with just extending the existing API. But this would mean, that from there on this lib is more than just a transparent wrapper for libmosquitto and would probably involve some additional documentation work since you can not simply refer to the mosquitto.h and say this is our API.

I would say the biggest work in this PR was the properties parsing back and forth so changing the design decision on this point might not be catastrophic.

I like the current approach more because it is way more explicit but I am open to your final decision :)

lua-mosquitto.c Outdated
@@ -539,7 +577,7 @@ static int ctx_threaded_set(lua_State *L)
static int ctx_option(lua_State *L)
{
ctx_t *ctx = ctx_check(L, 1);
enum mosq_opt_t option = luaL_checkint(L, 2);
enum mosq_opt_t option = luaL_checkinteger(L, 2);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this looks like an unrelated change? why do you need this?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I run into an compile error, because I forgot to set LUA_COMPAT_APIINTCASTS.

Change removed

lua-mosquitto.c Outdated
{"loop_forever", ctx_loop_forever},
{"loop_start", ctx_loop_start},
{"loop_stop", ctx_loop_stop},
{"socket", ctx_socket},
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

all the whitespace changes here make it harder to follow :|

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tried to revert the whitespace.

@karlp
Copy link
Contributor

karlp commented Jan 31, 2022

It looks like you've got v5 support in the general functions, and also _v5 suffixed functions? Does that really make it easier to use? In general this looks ok though, I've not tried any of it out though.

@niecore
Copy link
Author

niecore commented Feb 4, 2022

It looks like you've got v5 support in the general functions, and also _v5 suffixed functions? Does that really make it easier to use? In general this looks ok though, I've not tried any of it out though.

Yes you are right, I wanted to share some code but since this already lead to confusions, I changed the functionality now, so that the old functions are not touched.

@karlp
Copy link
Contributor

karlp commented Feb 4, 2022

It looks like you've got v5 support in the general functions, and also _v5 suffixed functions? Does that really make it easier to use? In general this looks ok though, I've not tried any of it out though.

Yes you are right, I wanted to share some code but since this already lead to confusions, I changed the functionality now, so that the old functions are not touched.

Oh, I'm not against the combined :) I actually suggested it in my issue discussing how this should be done, it just seemed to be not what you had said you had done :)

@niecore
Copy link
Author

niecore commented Mar 4, 2022

Hello @karlp , I am wondering If I could provide you anything more in order to help you with the review and merge.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

mqtt5 support API design?
2 participants