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

mqtt5 support API design? #26

Open
karlp opened this issue Mar 13, 2020 · 1 comment · May be fixed by #33
Open

mqtt5 support API design? #26

karlp opened this issue Mar 13, 2020 · 1 comment · May be fixed by #33

Comments

@karlp
Copy link
Contributor

karlp commented Mar 13, 2020

None of the mqttv5 support functions are implemented yet. I'm considering what the APIs shoudl look like?

I believe ~all of the _v5 functions should just be automatically called IFF properties are present as the final argument? Does this make it too hard to use the "sensible defaults" for all the other parameters?

ala:

-- old
publish (topic, payload[, qos=0[, retain=nil]])
--new
publish (topic, payload[, qos=0[, retain=nil[, properties=nil]]])
if properties are present, the _v5 function is called after constructing a properties set.

I believe the properties should just be handled as lua arrays, no need to expose all the internals here.
ala:

local props = {
   {m.PROP_RESPONSE_TOPIC, "some string"},
   {m.PROP_BLAH, 9999},
   {m.PROP_ETC, foo}
}
publish(topic, payload, 0, nil, props)

The lua lib can correctly create a proplist by type inspection.

I do NOT know how to best handle the callback registration. We can't always call _v5, as v5 might not be available. Do we have to store the v5 state from connect time or init time and then always use _v5 "as appropriate" ?

@theBASTI0N
Copy link

You could just keep them seperate.
Have publish_v5 etc then it would be very similar to https://mosquitto.org/api/files/mosquitto-h.html

It would make them very easy to distiniguish between and simple examples could then be maintained.

@niecore niecore linked a pull request Jan 25, 2022 that will close this issue
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 a pull request may close this issue.

2 participants