How about adding hook for PUBXXX messages

[ryskiwt]

Dear maintainers,

Is your feature request related to a problem? Please describe.
I want to set user properties on PUBACK, PUBREC, PUBREL and PUBCOMP.

Describe the solution you'd like
How about adding a hook function to ClientConfig like:

PublishResponseHook func(publish, pubresp *packets.Packet)

And this hook will be defined like:

paho.ClientConfig{
    ..snip..

    PublishResponseHook: func(publish, pubresp *packets.Packet) {
        pb := publish.(*packets.Publish)
        // do something by using publish's properties

        pa := pubresp.(*packets.Puback)
        if pa.Properties == nil {
            pa.Properties = &packets.Properties{
                User: []packets.User{Key: "hoge", Value: "fuga"},
            }
        }
    },
}

Then this hook can be used here:
https://github.com/eclipse/paho.golang/blob/76a1f9a081d13c3e6da7706c7dd3e24c8139d82c/paho/client.go#L315

like:

c.ClientConfig.PublishResponseHook(pa, &pb)

Thanks,

Ryosuke

[alsm]

What are you thinking of doing with the hooks? Puback and other such packets are really for the protocol and implementations rather than users.

[alsm]

The publish hook is before messages are sent to allow the user of the library to modify them, and currently to provide automatic topic aliasing.

[ryskiwt]

Thank you for reply!

I am currently developing an MQTT broker with its own extension specification. I would like to return additional information defined in the extension specification to the MQTT broker using UserProperty in PubAck, PubRec or PubComp messages.

However, there seems to be no library that has hooks like I proposed. If this library could support such hooks, it would save me a lot of time and effort to develop a client that supports the extension specifications.

[alsm]

I've been thinking about this, on the one hand this opens up a whole load of possibilities that weren't previously possible, and I don't think were imagined when the spec was put together, it will be quite possible to create tight coupling between an application and a specific broker.
On the other hand this opens up a whole load of possibilities that weren't previously possible and it might be exciting to allow that to be explored.
If anyone else is reading this issue I'd appreciate other thoughts.

[alsm]

Well, as no one else has responded I will have a go at adding this and see how it looks/feels. Not going to guarantee that I won't remove it in the future if I decide I don't like it :)