Meeting minutes
Previous minutes
<dape> March-7
Daniel: (Reviews the minutes)
… Minutes look good to me
… didn't see any issues to correct
… propose making them public
There are no objections
Quick Updates
Daniel: I would like to summarize the testfest/plugfest
… there is still some cleanup to be done
… unfortunately, we didn't test the Scripting API in its entirety
… I have the online things running, though, and updated them with the latest node-wot version
… did anyone else notice anything?
Cristiano: I didn't have time, unfortunately. I was thinking about stress testing node-wot in the context of MQTT
https://
Jan: I have a scripting API implementation written in Dart that could be tested and be added to the list of implementations
PRs
PR 381
<kaz> PR 381 - feat: reintroduce "local" discovery method
Daniel: PR is still stalled
Cristiano: We need to check the current status of the Discovery Specification and look into if "local" should be used
Daniel: We could also discuss moving discovery to the ConsumedThing class
… currently we are mostly a wrapper around the Thing
Cristiano: You mean the Directory API, right?
Daniel: Correct. There were points made by Zoltan if we should base the directory discovery solely on the TD
Cristiano: We should have another look into the Discovery Specification. Maybe we are a bit too late and can't do anything about it anymore
Zltan: Discover method is not a complete match for the Discovery Specification
… currently we only support Directory. You are right that we could get rid of the directory method if we use the TD. For the sake of convenience we could keep it. We need to make clear what is what.
… our Discovery API is not addressing the introduction phase, therefore we might need a different operational mode
… we can currently only use the operational mode, i. e. the environment is already set up
… in order to support local discovery, you need different hooks
… interactions with the local hardware are problem in cases like bluetooth
… for bluetooth, for example, you would need some kind of binding or bridge
… the Group needs to decide whether we want to support local discovery or if we should call what we already have "provisioning", for example
Daniel: If we don't have the local discovery and we only have the Directory then we could get rid of the discover method
Cristiano: I am okay with saying that Discovery methods are out of scope of Discovery API
… however, how do you let the introduction layer talk to the Scripting layer?
Zltan: If we have two runtimes, one running in provisioning and one running in operational mode. After the introduction phase you would have an URL that could be passed to the Scripting API. This URL might result in a URL
… for security reasons we cannot simply query all URLs. We need to formulate use cases for discovery.
Cristiano: Directory is more or less the trivial scenario, real world is more complex
Zltan: We could have a well known entry point that could map to initializing the Discovery process
… we should avoid side effects
Daniel: Let's assume we have the runtimes: Even with the API I am unsure how to describe this
… how do transfer information from one to the other?
Cristiano: That is what Zoltan was referring to. We currently lack implementations
… there is an implementation by Ben Francis' (Web Things) that uses multicast DNS
Daniel: In node-wot we never made it to implementing the discovery methods
Zltan: I think the reason was that it was ambigious.
… current approach is good enough in my opinion, Discovery Object can jumpstart discovery
… if we make the Discovery object a Promise than we can jumpstart it
Jan: I implemented direct and multicast methods
Zltan: Means we can implement it, we should look into how to integrate it in the API
… we should see how Web Things uses Multicast DNS
… maybe we can have a convenience method (in node-wot)
Cristiano: Maybe we can use a approach like dependency injection
Zltan: If we have local we could define what kind of "local" we mean.
… is very privacy critical, though
Daniel: Well-known concept might not work out if you have multiple instances of TDs, for example
Zltan: I think we should take it from a implementation point of view
… we have direct and multicast, we should see how local can be supported
… we can include a note in the specification that it is a experimental API
Jan: I will try to integrate my discovery approaches in node-wot experimentally
Consumer cleanup behavior
Cristiano: We have a problem in node-wot that CoAP clients are not being closed which causes hanging
… should we add something like a destroy method to the ConsumedThing?
… socket is currently not being closed. Problem is not limited to CoAP, however, also relevant for WebSockets, for example
Zltan: We discussed adding a destroy method to the ConsumedThing a few years ago
Cristiano: If we add a close/destroy method then we would introduce a state
Zltan: We could specify an InteractionOption that a Consumer should keep connections open.
Cristiano: In the case of HTTP connections are always closed after a request
Zltan: We can define a default value
Daniel: In the case of CoAP it might be a library issue. For WebSockets keeping connections open might be useful. For CoAP or HTTP is should not be used.
Zltan: A destructor is useful. The interaction option might actually expose too much procotol-specific information
… caching connections in the case of WebSockets etc. will be useful
<kaz> [adjourned]