Skip to content

mqtt5 support API design? #26

@karlp

Description

@karlp

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" ?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions