W3C

– DRAFT –
WoT Scripting API

19 December 2022

Attendees

Present
Cristiano_Aguzi, Daniel_Peintner, Ege_Korkan, Kaz_Ashimura, Tomoaki_Mizushima
Regrets
-
Chair
Daniel
Scribe
dape

Meeting minutes

Previous minutes

Cristiano: no meeting

Quick updates

Co-Moderation

PROPOSAL: Cristiano being the co-moderator of the scripting call. Will be announced in main call.

RESOLUTION: Cristiano being the co-moderator of the scripting call. Will be announced in main call.

PRs

PR#424

PR 424 - Fix internal slots

Cristiano: Updated notation for internal slots
… PR ready for review
… with latest respec configuration
… citing now uses proper definition
… ConsumedThing references are complete
… node-wot follow the same structure
… for ExposedThing ... some internal slots are missing
… for property internal slot has been added
… some todos
… internal slot for events
… check "subscribers" internal slot

Daniel: Shall we wait for the todos to be done in this pr?

Cristiano: Suggest to add todos in another pr

Daniel: Makes sense, will review after this call

Cristiano: OK, changed PR ready for review

<cris_> https://github.com/w3c/wot-scripting-api/pull/441

PR#441

<kaz> PR 441 - Align the discovery API with the Discovery spec

Cristiano: Gave review
… still need to check your comments
… propose to split one text in 2 different cases
… added another comment

Zoltan: pushed commit to split into 2 cases
… btw, filter is not supported

Cristiano: I think this resolves my first comment
… w.r.t. the 2 comment... I suggest to be more explicit

Zoltan: What about the other errors
… need to be more specific for other places as well

Cristiano: Could do the same as for fetching TD

Zoltan: If we go into those details.. we need to add a lot of details

Cristiano: I see
… maybe adding some explanation text might help

Zoltan: We need algorithm for fetching TDs
… not sure how to link it to protocol bindings

Cristiano: I guess we can resolve this comment also

Zoltan: Suggest to open new issue

Daniel: Should discuss this in new issue... but there are different uri schemes .. and many errors and such might pop up

Cristiano: I see

Zoltan: BTW, there is a complete spec that defines fetch...
… TAG might raise issues

Cristiano: I would point to protocol bindings ..
… anyhow, the PR looks good
… and I think we can merge... any concerns?
… -> none -> let's merge

PR#442

<cris_> PR 442 - fix: emitEvent() method allows data to be optional

Cristiano: Seems fixed and ready to be merged
… Zoltan approved also
… PR fixes issue with describing no data in event
… Daniel also updated TS definitions

Daniel: related to issue 445

Cristiano: Okay for merging?
… no concerns .. merging

Issue

Issue#417

<cris_> Issue 417 - emitPropertyChange does not take low-level event apis into account

Cristiano: Issue was opened by Ege
… he spotted some issue in new design
… added use-case description
… I responded to the use case
… from low level api point of view
… low level can offer different api
… 2 cases
… a) by listening to events
… b) polling
… the new design of emitPropertyCange
… we force to use read handler for property

Zoltan: might mean 2 rounds in implementation

Ege: not exactly for events/properties
… e.g., streaming value with property
… one needs to cache value

Cristiano: Not sure why get operation is needed
… you have already the correct value

Ege: IF I detect a change.. I want to send update
… interacts with sensor twice

Zoltan: Talking about implementations?

Cristiano: with cached values no second interaction is done
… some people might use a different approach..

Kaz: Meta question: Do we have concrete description of expected protocols?
… if we have enough knowledge we can think about the details
… 2 options
… give up for now
… or narrow the scope (some potential use-cases)

Cristiano: We have clear view of use case
… hard w.r.t. technology
… probably we need to study more libraries

Zoltan: Fear race conditions
… suggest to keep this issue open

Ege: I can have another look and provide more feedback
… in the end the current proposal is fine
… we just need to make developers aware of it

Zoltan: we do not guarantee that value is latest value

Kaz: we should look into popular methods in OPCUA, ECHONET, ...
… we can borrow their ideas

Cristiano: Agree

[adjourned]

Summary of resolutions

  1. Cristiano being the co-moderator of the scripting call. Will be announced in main call.
Minutes manually created (not a transcript), formatted by scribe.perl version 197 (Tue Nov 8 15:42:48 2022 UTC).