Meeting minutes
approving previous minutes
<kaz> Feb-14
Daniel: looks OK to me
… some minor indentation issue
Zoltan: it's fine
Daniel: there was one action and it's been done
Daniel: no objections, minutes approved
Daniel: new publication only after the discovery is agreed and reworked
Daniel: on open PR from Jan
Jan: it's a draft and will stay as work in progress
Issues
Daniel: Mostly about aligning discovery
… waiting until outstanding PRs are merged in the Discovery spec
Daniel: Also, we need to align with the Architecture spec (terminology)
… also, if we need changes in Architecture spec, we need to raise now
… so everyone please take a look
issue 363
<kaz> issues/363 Consuming composited Thing Description
<dape> Issue 363 - Consuming composited Thing Description
Zoltan: currently since we don't have an API for composite TD consuming, we need to consume as one TD and make it simple for the apps
Cristiano: the outstanding PR is specifying this part, we need decision how we want in the future
… in PR 272
354
<dape> Issue 354 - Conformance section necessity
Daniel: we discussed this in the main call several times
… I don't seem to have the right understanding, it looks OK
Kaz: the point here is whether the WoT WG as a whole wants to publish the Scripting API spec as a Note including normative portions or not. that should be OK if the group makes such a resolution.
Daniel: for me it is important to have the conformance section, to refer to it
Zoltan: same here, we have 3 conformance classes that would be hard to express in other ways.
Daniel: it also depends on how the other task forces will publish the Notes they are working on.
Kaz: the groups chair said everyone should read the Scripting API Note and make an informed resolution on 23 February main call.
Kaz: we need to follow the procedure and have the whole WG's resolution
Daniel: that sounds good
issue 364
<kaz> 364 Using a callback-based approach for Discovery?
<dape> Issue 384 - Using a callback-based approach for Discovery?
Zoltan: the only problem with async iterables is lack of support in small JS runtimes, but it's supported in Node.js and the browser, too
Cristiano: with notifications we have events (async), but in this case we have as result a TD, and it's less probabilistic (e.g. a list of TDs)
… in this case, the async iterators work well.
… since the use case is different from Subscription, it is justified to use async iterators
Jan: canceling discovery should also be supported
… the previous design had an issue with the implementation, async iterators don't have that problem and the API is cleaner as well
Zoltan: the discovery object is still a subscription, but now instead of next() method it is iterable - but still has the stop() method.
Daniel: the direct case with separate method looks like a fetch, not like discovery
Zoltan: is there any extra semantic info with direct discovery?
Cristiano: in principle it is an introduction mechanism
Zoltan: that is a difference we need to align between the task forces
Cristiano: yes, previously it was a fetch, but now it's like an introductory mechanism in the Discovery spec
Daniel: if you call a direct discovery, you get one TD, which can be the TD of a directory
Zoltan: then we should define another API for introduction and not name it "direct"
… but we could keep the direct method
Cristiano: yes, it is more like a use case for "direct" fetch of a TD
Zoltan: so we need to align now these use cases (direct, directory, introduction) and maybe the API needs changing
Daniel: if I call discover(), I get TDs of Things
… but now we can also get a list of directories (as well)
Cristiano: yes, this is under work now in the discovery TF - and the behaviour is optional
… maybe indeed we should wait a bit until this is decided
… we need to keep a close eye on this
Jan: maybe the direct method could behave differently, depending on the return type (TD or directory)
Zoltan: let's try to cleanly separate the use cases vs API, and not multiplex based on returned content
Daniel: we should stop here and think about it
Cristiano: if we need to check the returned content, we cannot do streaming TDs since we need to wait and decide and act
Zoltan: we can do streaming use case with the current API, using a TD that specified a content type as a binary (streamed) TD content, and fetch with the current API
issue 384, aligning discovery and scripting
Daniel: we need to be aware of the differences and communicate to the Discovery TF
<dape> Align discovery and scripting
issue 382 github actions
<dape> Issue 382 - Sync ThingModel action failed
Cristiano: we need to do the proper sequence for the actions - in theory they could run in parallel, but there are issues
Daniel: the sync should succeed, so if one triggers the other, it should be fine
Cristiano: OK, will settle that
package lock file
<kaz> Issue 379 - ThingModel TypeScript defintition misses package-lock.json
Daniel: there should be one lock file, and none in the subdirectories
… I can provide a PR
Cristiano: it's mainly for the CI
… no dependency, just development tools
Daniel: need to leave earlier today
adjourned