W3C

– DRAFT –
WoT Scripting API

13 May 2024

Attendees

Present
Cristiano_Aguzzi, Daniel_Peintner, Jan_Romann, Kaz_Ashimura, Tomoaki_Mizushima, Zoltan_Kis
Regrets
-
Chair
Cristiano
Scribe
zkis

Meeting minutes

approving last minutes

<cris> https://www.w3.org/2024/03/18-wot-script-minutes.html

Approved

Next calls

Cristiano: we should reflect the biweekly meetings in the calendar

Jan: maybe we can cancel the ones we skip

Zoltan: if the meeting falls on a holiday, do we skip (i.e. 4 weeks without meeting)?

Cristiano: yes

Kaz: we can change the calendar entry to biweekly
… I can give the permission for that

Daniel: it has pros and cons; currently we have the freedom to align better with public holidays

Kaz: if all is fine with specifying biweekly calls, technically we can do it; but if we do it manually, we need to send email notifications every time

Zoltan: in some groups the biweekly meetings are announced by email a week earlier with the agenda - that has been a good practice

Cristiano: yes, but are you fine with changing to biweekly meetings?

Zoltan: yes, but IMHO it would be a good practice to announce the meetings by email

Cristiano: OK

CA has changed the calendar - will send notifications

PRs

PR 550

<cris> PR 550 - refactor: align with latest marketing template

Cristiano: this comes from the Marketing TF

<dape> rendered version at https://github.com/w3c/wot-scripting-api/blob/319786f8ed8e6a81e306cd331e6da69170f237f0/README.md

Cristiano: a general alignment template for task forces

Cristiano: merging the PR

Kaz: the proposed readme is not just for Marketing but all the WoT task forces activities

Kaz: so the PR title was not entirely correct, but the content was OK

PR 549

<cris> w3c/wot-scripting-api#549

Daniel: the reason was that Eclipse repo hierarchy was changed
… also http changed to https

Cristiano: ok, we can safely merge

PR merged

PR 545

<kaz> PR 545 - feat: expand exploreDirectory algorithm

Jan: no updates on this yet, it still needs work

issues

issue 548

<cris> Issue 548 - Support for additionalResponses

Cristiano: this comes from Luca
… it brought up something we need to implement, and even spec
… the spec doesn't mention how to handle this case

Cristiano: things become tricky when additional responses refer to their own schema

Cristiano: currently this is categorized as spec improvement

Daniel: the opening comment we need to correct

Cristiano: good catch

Zoltan: we can make a note, give a scripting example, eventually we can make an algorithm

Daniel: when additional responses are more than just success/errors, then how to handle that?

Cristiano: the schema of the output property should reflect also the schema of the additional responses
… but we don't say anything about it now
… somehow the runtime needs to figure it out

Daniel: so it's a bit of a grey area

Jan: not sure how well can we generalize this, as it's HTTP specific...
… a general algorithm should also handle other protocols
… maybe in the bindings

Cristiano: right, this is coming from HTTP

Cristiano: CoAP might be OK, but MQTT might be different

Cristiano: what is important is the mapping, including error mapping

Zoltan: this shows the importance of scripting APIs, since it can model all these protocols with the same API
… we need to give explicit examples for how to handle these situations
… the best is to solve it in the bindings / TD spec.

issue 535

<kaz> Issue 535 - Dedicated methods for DNS-SD, CoRE Link-Format discovery, and other approaches?

Jan: it's about if the Discovery TF introduction methods can be modeled explicitly
… or are we fine with generic API
… or whether these should be added by libraries
… not sure how to move on

Cristiano: IMHO it's quite hard to unify all introduction methods in one method

Jan: maybe we could just request a TD and explore that
… was not sure how the "magic" discovery would work

Zoltan: it all depends how much functionality do we want to expose in the app side from the implementation side

Cristiano: most people seem to have some kind of directory which they explore

Jan:

Jan: maybe having the general way of discovery is nice, but was wondering is how to best configure this

Zoltan: we used to have some but they can change

Jan: I gave an example in the issue

Zoltan: right, those have been supported in the past, we can extend the filters

Jan: right, we can experiment more on this

Cristiano: we could label features as experimental and gather more dev feedback

Cristiano: maybe even during a plugfest

Cristiano: time is up, AOB?

Meeting adjourned.

Minutes manually created (not a transcript), formatted by scribe.perl version 221 (Fri Jul 21 14:01:30 2023 UTC).