W3C

– DRAFT –
WoT Scripting API

07 February 2022

Attendees

Present
Cristiano_Aguzzi, Daniel_Peintner, Jan_Romann, Kaz_Ashimura, Michael_McCool, Toamoaki_Mizushima
Regrets
Zoltan
Chair
Daniel
Scribe
dape, kaz

Meeting minutes

Previous minutes

Jan-31

Minutes approved

PRs

Fix #355: change use cases,

PR 375 - Fix #355: change use cases

McCool: the text "The following scripting use case scenarios are supported" is fine

Kaz: agree. so would suggest the title also should say "Scripting Use Case Scenarios".

Daniel: suggest to wait for Zoltans feedback

Issues

Using a callback-based approach for Discovery?,

364 - Using a callback-based approach for Discovery?

McCool: discovery API should deal with all possible options

<kaz> 10.2 The DiscoveryMethod enumeration

Daniel: we currently have direct and directory

Cristiano: w.r.t. registration is left to runtime
… shall we make this explicit

McCool: self- description is another argument
… like .well-known

McCool: need to re-read the scripting spec
… generate issues for missing features

Cristiano: I suggest to wait for feature freeze of discovery

McCool: should happen soon

Cristiano: exploration methods only ?

McCool: simple call, just "discover"

Cristiano: problematic to be implemented

McCool: testing of discovery
… client-side implementations
… "introduction" is open-ended
… DNSD should be supported
… need external management API

Daniel: Separate API

Cristiano: filtering TDs (query) ?
… tricky to filter

McCool: Filters are a real problem
… SPARQL is heavy weight
… JSONPath is not ready yet
… XPath lacks implementations
… we ended up not having mandatory query mechanism
… should support filter like JSON-Path in node-wot
… do apply filters locally

Cristiano: not suggest JSONPath on client-side
… implementation burden

Cristiano: application knows TD
… how can I fetch TD
… using discovery API?

McCool: optional argument is fine with URL
… description of discovery process is missing
… set of TDs

Cristiano: discovery process would be great, we just follow
… Scripting task-force needs to review the process

McCool: need to still describe it
… proposed text in introduction section

Cristiano: Sounds great

Daniel: different discovery entry points

McCool: options to set
… we might want to have multiple options

Cristiano: JS allows to check for which method is supported

McCool: configuration option might be better

McCool: "automatic" method is missing
… I am working on integrating discovery services

Daniel: unsure about "automatic" method

McCool: question about limiting the scope
… in local networks it might be fine

we lack geo-spatial control

McCool: discovery does support mDNS etc
… "local" could be local discovery (like "automatic" in local network)

Cristiano: what about BT ?

McCool: is local

Cristiano: What about process?
… partially describe it

McCool: there is an informative description
… should make it more formal
… but we are running out-of-time

Daniel: timeline?

McCool: overdue, last week
… best we can do, having informative description

<McCool needs to leave>

McCool: will create issue with adding "local" back
… will re-read the document
… self-description

Cristiano: left to implementation?

McCool: when exposing ... like under .well-known
… how to decide where to broadcast

Cristiano: opposition in scripting: expose() makes it available

McCool: self description should not be required.. there might be cases you don't want

Daniel: Issue with having *one* TD only on .well-known

McCool: working on fixing it
… look for simple mechanims
… thing-links
… pointing to other TDs ... index on host
… several runtimes on same host is problematic

Cristiano: Suggest to wait for feature freeze
… w.r.t. "local" ... I am surprised .. but god the point from McCool
… should re-iterate on API... e.g. from Jan

Cristiano: should try to have another call with MMC

<kaz> [adjourned]

Minutes manually created (not a transcript), formatted by scribe.perl version 185 (Thu Dec 2 18:51:55 2021 UTC).