Meeting minutes
past minutes
<kaz> Mar-28
Daniel: we discussed discovery and consequences to Scripting
Daniel: no objections, meeting minutes accepted
issue 376
<dape> https://
Daniel: about alignment with Architecture doc
Daniel: I provided feedback and a PR with small changes
Cristiano: we can close it and check back later
issue 388
<dape> https://
Daniel: sometime we are not sure we get back any data from an interaction
Daniel: we could look at DataSchema, but return value might be optional
Daniel: the idea is to tell the scripts by a flag if there is any data at all
Cristiano: wondering if that is useful
… we could have 2 options: when reading value, we get undefined, or we read the stream
Cristiano: so IMHO this is not strictly needed, but would delay exposing this until a real need arises
Daniel: we had a too generic interface that didn't go in the DataSchema, maybe an implementation issue
Zoltan: in InteractionOutput interface we can use the nullable 'data' property to tell there is no data
Zoltan: we could also include an extra step in the value() function to return NoData or similar
Cristiano: there could be cases of empty stream, that should return undefined
Zoltan: but we would use the reject path to tell there is no data
Cristiano: right
Zoltan: so we need to check the steps for value() and reading data
Daniel: we need examples
Cristiano: ConsumedThing examples
Daniel: maybe we need to look into the implementation
Zoltan: is there any validation in node-wot to check if the spec is implemented correctly?
Daniel: there are tests but no formal process for that yet
Cristiano: yes, we have some unit tests and we need to review them to make more close to the spec
… but how to ensure the tests themselves are correct - we still need human code review
… then the test suite can be used by other APIs as well
Daniel: bindings make it difficult
Jan: and only for consuming things, not for exposing
Daniel: again the question of REC track raises, together with tests
… for time being, we seem to agree we don't need a separate flag, but revisit the algorithms
Zoltan: yes
Daniel: ok, I am fine with that.
issue 392
<dape> https://
Daniel: to fill use cases concerning Scripting API
Zoltan: scripting API is a tool, not a use case itself
… it can be used as a tool to implement other use cases
Daniel: so what should we do here?
Zoltan: IMHO nothing - maybe clarify the expectations
Cristiano: same here, more information is needed
Jan: one distinction we could make is machine-to-machine and machine-user interactions
Cristiano: isn't this about requirements?
Zoltan: but scripting is not specific to these use cases, since it's generic and tied to the TD spec
Kaz: we need to discuss it in the Editors call and the use cases call
… each proposer of the use cases themselves should look into all specs and check if the use case is covered
… and ML's policy is to ask the editors to make that check
Daniel: so we should ask ML to turn the question not to editors, but to the writers of the use cases
issue 395
<dape> https://
Daniel: about closing connections from ConsumedThing
Daniel: scripts should be able to close a connection or clean up
Zoltan: on ExposedThing we have destroy()
… and start()
Cristiano: we can use separate connection on each request
Daniel: how do we do with a websocket?
Zoltan: is it enough to have destroy() on ConsumedThing as well?
Cristiano: since we need a Form for interactions, we cannot really make a connection when constructing ConsumedThing
Daniel: if we had destroy(), it would make the object unusable?
Cristiano: semantically speaking yes, a new consume is needed, but technically we can implement it to reconnect
Zoltan: we can name it other than destroy()
Daniel: if we can reconnect again and again, do we need destroy()? since each impl could have an internal timeout
… to release all connections
Jan: I tried to implement that experimentally to manage hanging CoAP clients, needed to close connections after each request, but needed a method to stop all subscriptions and network activity
Zoltan: we can also have start() and stop() methods
Daniel: for websockets, if we close on every request, isn't that too much hitting performance?
Jan: good question
Cristiano: destroy() or stop() can be implemented by the apps, so not strictly needed
… but for websockets, timeouts are still workarounds to close resources
… other solutions are not using this
… we can recommend developers to use timeouts?
… there are servers to handle thousands of active websockets at a time, it would be good to be able to close sockets when not used
Cristiano: we need to handle various scenarios, that's the problem
… for CoAP is fine to force closing the connection for each request, but for others it might be
Jan: if we have CoAPs, and we connect from constrained device, we should be able to reuse the same connection for multiple requests
Zoltan: I suggest we take these scenarios each, since there are 2 different policies, freeing up connections as resources, and reusing connections
Jan: also shutdown() is a possibility
Zoltan: shutdown() and destroy() are final, I would use start() and stop(), as also used in other specs
Cristiano: right now the start() method doesn't have any relevance
Daniel: let's continue on github
adjourned