WoT Scripting API

09 May 2022


Daniel_Peintner, Jan_Romann, Kaz_Ashimura, Tomoaki_Mizushima, Zoltan_Kis

Meeting minutes

Previous minutes

<dape> May-2

Daniel: reviewed a list of issues
… issue 392 is stalled
… we also discussed consumer cleanup
… it was a short meeting
… minutes approved?
… ok


Daniel: two PRs: one stalled and one from Cristiano
… Cristiano's PR is about cli sync failures

PR 397

<kaz> PR 397 - fix(cli): use autostash option when pulling

Daniel: there's a sync action that pull changes from TD repository and check updates on the schema

Cristiano: just a minor change to prevent git failing due to dirty stage

Daniel: ok let's try if it solves the issue
… is it ok for everybody?
… ok merged


issue 396

<dape> Issue 396 - The future of the conformance class WoT Discovery

Daniel: Internally in siemens we discussed about the discovery process
… currently the discovery conformace class it was more sophisticated
… we could do multiple types of discovery
… even local
… now we simplified it with just two methods
… direct and directory
… we are discussing to bring some functionalities back like local
… keep in mind that the discovery process is split in twos
… introduction
… and exploration
… the discovery goal is very simple
… get a TD
… is similar to "fetch"
… supporting the whole Discovery spec it gets complicated
… maybe it easier right now to narrow the scope

Zoltan: what is the beginning and the end of the process from the API point of view.

Daniel: my point is that do we need really this complex interface?
… maybe fetch is already sufficient
… what is local?

Zoltan: the definition is still a To do in our spec
… are you suggesting that from a directory I can fetch a list of urls that we can directly download later?

Daniel: good point
… in practice if I want to discovery TD using Bluetooth
… I would use a bluetooth library
… and configure it in a bunch of ways
… and probably do additional steps
… there's a lot of details
… and local is even harder to define

Zoltan: what do people do in plug fest?

Daniel: direct
… and directory

Zoltan: the discovery API should tackle with how to retrieve TDs

Cristiano: m-DNS was also used in plug fest

Zoltan: we have a clear chain
… discovery gets TDs and consume use them
… we need to stick with the frequent use case

Cristiano: I suggest to read section 5 of the discovery spec
… it helps the discussion a lot

Zoltan: still not clear how it connects with what other platforms does in the provisioning phase
… we can use the document to engineer APIs
… and maybe ask for review to the discovery task force

Daniel: we removed fetch
… because we would need to provide working code for every URLs
… with the introduction mechanisms is the same
… you'll get a mess

Zoltan: but we can choose one, the spec describe a general implementation the API can be one of those
… we should follow the use cases
… when you open protocol specific it becomes difficult to write applications
… that's the whole point of WoT

Daniel: if you want to provide support for direct with direct
… we still have a problem to support any URI scheme
… in the past we concluded that you can do it outside from the scripting api

Cristiano: not any URL schema but just the one supported by WoT

Daniel: not sure if there is some benefits of having a discovery API
… Jan do you have any feedback ?
… do you see the benifit of having this API?

Jan: coap multicast would be nice to have
… but it could be implemented outside
… simplifing the api
… introduction and explorartion phases are a little bit hard to understand

Cristiano: but still we need a sort of discovery API to build "cross-platform" application

Daniel: we also discussed to split the API in two
… because they have different security requirements
… but I see the benifits of having such of API but I'm start thinking it's hard to achive

Zoltan: hub setups are pretty common
… so directory method might be use 90% of the times
… provisioning is out of scope
… I think we should understand the requirements described in the discovery spec

Daniel: I agree
… going back on use cases
… are you sure that directory is the most common?

Zoltan: we have to ask

Daniel: maybe multi cast is more used

Cristiano: sometimes is even mixed with directory + m-DNS

Zoltan: we eventually defined local bluetooth, wifi and NFC

Cristiano: maybe generilize saying radio protocols?

Daniel: how should we proceed ?
… should we continue the discussion on the issue

Zoltan: we can even talk about API design
… we can forward the task to the discovery task force

<JKRhb> https://github.com/namib-project/node-red-contrib-wot-discovery

Jan: multicast we have a library in node-red
… but for security reasons is deprected in most scenarios.

Daniel: in the end is up to the runtime like node-wot

Cristiano: proposal, why don't we try to discuss the requirements and API design in the issue
… and after talk with the Discovery Task force

Daniel: yes
… we used a lot of time in discovery
… but it was worth it
… we are getting a lot of issues on it


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