Daniel: reviewed a list of issues
… issue 392 is stalled
… we also discussed consumer cleanup
… it was a short meeting
… minutes approved?
Daniel: two PRs: one stalled and one from Cristiano
… Cristiano's PR is about cli sync failures
<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
<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
… 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?
… 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
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
… we used a lot of time in discovery
… but it was worth it
… we are getting a lot of issues on it