Can't invoke an action with the current MQTT implementation

[relu91]

As well described by @alvarogar23 in #456 (comment), it seems that with the current implementation is not possible to invoke actions using MQTT. In the comment above he pinpointed a particular line that is causing the issue: var topic = requestUri.pathname.slice(1)

Checking the git blame it seems that it was updated by @JKRhb. I vaguely remember the reasons why we applied these changes, maybe @JKRhb would you like to refresh my memory? was it something about how we handle topics, right?

For reference here's one of @alvarogar23's TDs:

{
    "@context": "https://www.w3.org/2019/wot/td/v1",
    "title": "AireAcondicionado",
    "id": "urn:dev:wot:mqtts:AireAcondicionado",
    "actions" : {
        "OnOff": {
            "forms": [
                {"href": "mqtts://localhost:8443/AireAcondicionado/actions/OnOff"}
            ]
        },
        "incrementar": {
            "forms": [
                {"href": "mqtts://localhost:8443/AireAcondicionado/actions/incrementar"}
            ]
        },
        "decrementar": {
            "forms": [
                {"href": "mqtts://localhost:8443/AireAcondicionado/actions/decrementar"}
            ]
        },
        "leerTemperatura": {
            "forms": [
                {"href": "mqtts://localhost:8443/AireAcondicionado/actions/leerTemperatura"}
            ]
        }
    }, 
    "events": {
        "estadoTemperatura": {
            "type": "integer",
            "forms": [
                {"href": "mqtts://localhost:8443/AireAcondicionado/events/estadoTemperatura"}
            ]
        } 
    } 
}

[JKRhb]

Checking the git blame it seems that it was updated by @JKRhb. I vaguely remember the reasons why we applied these changes, maybe @JKRhb would you like to refresh my memory? was it something about how we handle topics, right?

Yes, this was related to #255. The addition of var topic = requestUri.pathname.slice(1) was supposed to enable the use of topics that don't start with a / as node-wot always seems to treat href as a (relative) URL. The fact that this prevents the use of topics that start with a /, however, is of course not ideal as those are valid topics (although they are not recommended to use).

This should be easy to fix if there is only the topic provided in the href with the broker being provided in the base field. However, in this particular case we have the problem that an href like

"href": "mqtts://localhost:8443/AireAcondicionado/events/estadoTemperatura"

could represent both the topic /AireAcondicionado/... (with a leading slash) and AireAcondicionado/... (without a leading slash). I guess this problem arises from the fact that topics are not supposed to be part of a URI but should be provided separately. In this case, I suppose, we only have the choice between topics that always start with a / or never start with one.

I would soon open a PR for the case where the href is only representing the topic itself if you are not already working on a fix. The case where you have an absolute URL pointing to a broker with a topic, however, probably needs some more discussion.

[relu91]

I would soon open a PR for the case where the href is only representing the topic itself if you are not already working on a fix. The case where you have an absolute URL pointing to a broker with a topic, however, probably needs some more discussion.

It would be cool if you provide a PR for that. About the discussion, I think it should be solved in https://www.w3.org/TR/wot-binding-templates/

[JKRhb]

I have only now managed to come back to this issue and I noticed that this approach:

This should be easy to fix if there is only the topic provided in the href with the broker being provided in the base field.

it is not actually possible to implement solely within the MQTT package at the moment as all relative href URLs are converted into absolute URLs in the parseTD function. Therefore, I guess we have to decide whether we want to use topics with or without leading slashes as the default and/or let the consume function handle TDs with an MQTT base URL differently.

[danielpeintner]

Related: The reason why the parseTD() function converts all hrefs is to make it simple to pass along forms without any need to external knowledge (i.e., base).

The alternative would be to always need the combination of form and base.

In the past I encountered one another issue why we should not to this initial replacement (I just can't recall anymore what 🙈) .. mhh
Anyhow, if there are more good reasons we might rethink our strategy. Any thoughts?

[JKRhb]

The alternative would be to always need the combination of form and base.

Sounds like a good workaround for now :) Would this constitute a breaking change, though? Or are the functions for the actual triggering of interaction affordances (like, for example, invokeResource) only used internally?

[danielpeintner]

You raised a good point. At the moment all calls in protocol-interfaces provide the form only.

Hence, this is a breaking change for all bindings. We could provide a helper that takes base+href and creates the correct absolute href but yes, it would still remain a breaking change!

[JKRhb]

That is unfortunate :/ Should this change be considered for version 0.9.0 (or even 1.0.0) then?

[relu91]

Is this somehow related to #496 ?