Previous minutes

<kaz> Mar-2 Scripting call minutes

<kaz> Mar-16 Virtual F2F minutes - Scripting session

<inserted> scribenick: kaz

Zoltan: any problems with those minutes?

<inserted> scribenick: zkis

No objections, meeting minutes accepted

Issues discussion

Zoltan: if there are things to follow up, please create issues
... we have agreed on how to move on regarding issue#201 https://github.com/w3c/wot-scripting-api/issues/201

issue#208 https://github.com/w3c/wot-scripting-api/issues/208

Zoltan: the Oracle TD example raises questions regarding subscription data, passing keys etc

McCool: maybe using hypermedia would be better; it depends if this describes existing system or is it a wish list

I believe TD eventing is still underspecified, more work needed

McCool: we need to separate what is in TD and protocol binding
... we could also have a web hook
... if we put public keys in the TD, we also need to sign it

Zoltan: we need a mechanism that apps could manage keys
... we should maybe invite M.Lagally to next meeting

McCool: the cancellation uses id or URL; how is that handled in Scripting

Daniel: this is very underspecified
... maybe works for Oracle, not sure if works for others
... subscriptions should be by name and the runtime would associate that with bindings information

Zoltan: this looks like protocol bindings data that could be hidden behind the name to subscribe to

McCool: we need to specify this
... we should check events for TD v2
... we need to solve this quickly

Zoltan: otherwise including these details would end up fragmenting WoT

Daniel: checking the TD spec for how well Events are specified
... looks like a placeholder, it's not specified well
... we need a solution that works through all the use cases

McCool: these look like actions (when return type is different)

Daniel: we could also expose the whole thing to the apps

McCool: or standardize the mechanisms

Zoltan: is the subscription data always a DataSchema?

McCool: it could be anything

Daniel: these are just placeholders, they need more work

McCool: there are uncertainties how this works in practice
... is output data different schema than input data?
... when I make a subscription, I get back a data that is not the regular event data
... but a subscription id or something
... later it might send data
... but it also might send data right after the subscribe call

Zoltan: event data is always dispatched separately from the subscribe call

Daniel: if we ask for subscription, we should get some feedback or return value

McCool: we could have an Action for subscription
... we'd need to spec how to identify id in subscriptions in order to automate
... even if the protocols bundles together data and subscription return, data is dispatched separately

Zoltan: right, it should be separate

McCool: we don't have means in the TD to handle subscription id's
... we can have a best known method for TD v1 and make it a mechanism to annotate subscription id's in TD v2

Daniel: open an issue on the TD spec

Zoltan: some data needs to be opened up to apps, the question is how much (key management etc)

McCool: but that could be done in the setup phase

Zoltan: should we standardize interaction setup?

McCool: using shared secrets in an interaction should be annotated as such so that the runtime could handle it automatically

Zoltan: sounds good

McCool: I would flag this as an issue
... if the runtime is responsible for this, how to do it

Zoltan: maybe create an issue in TD, security and scripting

McCool: also, need to design how to handle MQTT
... the web hook was needed for instance

<kaz> TD draft - 5.5.1.5 EventAffordance

Daniel: will create the TD issue

Discovery API

<kaz> Issue 206

McCool: we can discuss this in the Discovery call
... we need to experiment with this

Zoltan: we could have a local directory to the runtime

McCool: we need a PoC, Singapore also interested
... the scripting API works in the 2nd phase (after onboarding etc)
... during onboarding, it's another API that should be used

Zoltan: when you have the Scripting API object, the device is already onboarded

McCool: it is also a virtualization issue
... if an app specifies a mechanism the implementation does not need to respect it

Zoltan: right, and currently they get an error

McCool: the directory mode should always work
... like delegating discovery

Zoltan: apps can specify no mechanism, then the runtime will choose the best or all available
... looks like we agree on discovery

McCool: We need fully specified filters
... including one for location
... need to look into the Location API

Zoltan: those are pretty easy to make an API for if we know the use case

McCool: will discuss in the Discovery call
... there could be filters specific to directories
... also, we need to spec the semantic queries
... like SPARQL support
... keywords and templates should be specified

Daniel: is the list of discovery use cases complete?

McCool: we miss templates from there

Daniel: we miss that from the use cases but support it in the API

McCool: partial TD?

Daniel: yes

McCool: semantic queries is a bit of a question, maybe partial TDs would be enough

Zoltan: semantic query requires an infrastructure we currently have not discussed yet

McCool: maybe the partial TD filters should be enough
... let's document and use that first

[adjourned]