ProtocolClient Interface does not allow to specify the affordance name, if the information is not contained in the Form

[RobWin]

The implementation of the ProtocolClient methods in node-wot assume that all the information needed to read a property, invoke an action or subscribe to an event is contained in a Form. See https://github.com/eclipse-thingweb/node-wot/blob/master/packages/core/src/protocol-interfaces.ts#L48
When implementing a websocket binding based on the Webthingprotocol, we saw that this is not the case for all protocols.
We had a long discussion on Discord about it. And in the Webthingprotocol spec the form href will not contain a property name or action name, so we would need to overload ProtocolClient methods with additional versions which also take the names as an input parameter.

[danielpeintner]

It seems that the readResource() / writeResource() / invokeResource() / invokeResource() / unlinkResource() method calls could be extended to hand in the interaction name.

Having said that, I wonder what is the best way forward with the following aspects in mind:

• most bindings don't need it..
• failure cases: property names might be different.. What should happen?
• backward compatibility (adding and optional argument or require this new argument)
  • if optional, failing if needed?
  • more aspects?
• is the name of an interaction enough, or might we need to add more (maybe in the future?) --> adding an (optional) object instead?

Any opinions?

[RobWin]

In kotlin-wot I modified ConsumedThing.readProperty to call client.readResource(affordanceName, form).
In the ProtocolClient I added a new overloaded method with a default implementation.

  suspend fun readResource(resourceName: String, form: Form): Content {
      return readResource(form)
  }

Thus I didn't have to modify existing bindings, but can override this new method in the WebsocketProtocolClient.

But Typescript cannot have default implementations in interfaces or?

But I agree a single Resource object as an input parameter would be more flexible to extend, but it would introduce a lot of optional fields. But that would be fine, since the ProtocolClient implementation could use the fields it requires.
The Resource object could contain a name, form and in the future additional information. Maybe tracing context metadata which needs to be added to a protocol request?
Right now the protocol client does not allow a ConsumedThing implementation to attach additional tracing context to a protocol communication.
I actually prefer to have an object as an input parameter instead of a list of individial parameters 👍

[JKRhb]

In dart_wot, I actually had a similar problem and solved it (for now) using an additional AugmentedForm class, that contains references to both the related interaction affordance and Thing Description. Having a best practice here across implementations would definitely be nice.

[RobWin]

Indeed, we need an object (or AugmentedForm), because the thingId is also required in the WebthingProtocol websocket messages.