Meeting minutes
previous minutes
<dape> https://
Daniel: in the end no need to shift the call time
Daniel: no objections, the minutes can be published
quick updates
Publication in Q1
Issues
Issue 365
<dape> https://
<kaz> Issue 365 - Recent ReSpec Warnings - Found definition for "XYZ", but nothing links to it.
Zoltan: business as usual, as ReSpec is evolving with new checks, we should periodically update the spec
Cristiano: it's a sanity check which is fine. In other case the references don't use correct syntax which is why they seem to be unreferred terms. We need to fix those.
Daniel: could try to do that
Kaz: we need to look for the reason for errors in our index.html, and if it's the case, we might want to raise issues against ReSpec
Daniel: some errors relate to the spec being on the REC track, not a Note
Kaz: we can change in the header
multiple properties
<dape> Issue 219 - Discussion about read- write-/multipleproperties
Cristiano: didn't we reach solution last time?
… we took an action point last time
Cristiano: the TD spec should be more specific on these
Zoltan: yes, including the error cases
Daniel: we opened issues on the TD spec on these, but no progress so far
Daniel: will ping the TD TF to expand on these
Zoltan: on the write/read multiple we know what to expect, but write/read multiple vs all is not specified well
callback based discovery
<dape> Issue 364 - Using a callback-based approach for Discovery?
Jan: summarizes the issue
Cristiano: we could do a pro/con summary on the suggestion
… similar to what we do on events
Zoltan: let's try to rewrite the algorithms based on this proposal and see how it works
Cristiano: about the next() method, it is controlled by the application, the alternative would let the runtime handle it
Cristiano: looks like the version with next() can be optimized better
… the app can stop when it finds what it wants
Zoltan: not all that much different from typical code with listeners either
Zoltan: let's analyze this more and weight the pros and cons
Jan: the question was in implementing the specified algorithm, to block until a TD is available
Zoltan: indeed the implementation difficulty is a valid reason to reconsider the API design, if the app can do the same things with the new design
Daniel: a naive thinking is that we get the ThingDiscovery, we could re-formulate the behavior, i.e. not wait on next() if nothing is available.
Zoltan: then it's easier to go with the listener model
… if the apps don't need that extra control, we can go with the simpler listener model
Cristiano: we use TD directory, that API is not finished yet, so we don't know about strong use cases yet for app side control
Jan: we could introduce more control with the listener model?
Daniel: let's continue in the issue
conformance
Daniel: waiting for feedback from Philip
Kaz: no answer yet, but will ping on IRC
thing models
<dape> https://
Daniel: CA should update
Finding correct unsubscribe form
find correct unsubscribe
<dape> https://
multiple subscriptions
<dape> https://
Cristiano: we have a PR on this
Daniel: we can close it then
Daniel: adjourned