Meeting minutes
previous minutes
<kaz> Oct-17
Daniel: we missed 2 calls, will continue where we left off
Minutes approved.
publication schedule
Daniel: the current charter ends Jan 2023
Zoltan: I suggest to finish the discussion on the discovery API changes and get it reviewed and published
Daniel: since the review time requirements, we should ask for review latest by Jan 9
Daniel: will be on vacation the week before
Kaz: we should think about charter and publication separately
… focus on what the Scripting TF can do
Daniel: so final draft should be ready by end of year
Zoltan: we have 5-6 meetings, should be enough for this objective
Kaz: Scripting being a Note, the date is less of a concern than the content of the proposed changes
Daniel: we agree that discovery should be the content
<cris__> +1
Daniel: we should agree on an interface that we can also implement
… next, the new op values
… we have some PRs in work
PRs
PR 438
<dape> PR 438 - fix: remove mentioning of internal discovery results
Daniel: fix ReSpec errors
Jan: this just removed the internal slot
Zoltan: we need a larger change that consistently updates the algorithms for using async iterators
Daniel: the change looks enough for me
Zoltan: I suggest we leave the PR open and maybe other changes will be needed as well
Jan: okay with that
PR 434
<dape> PR 434 - feat: adjust ThingFilter and ThingDiscovery interfaces
Jan: will continue with that next week
Daniel: we need multiple alternative PRs
Cristiano: indeed, planning to do that ASAP
Zoltan: we can also work in issues and first agree on the web idl
<dape> Issue 364 - Using a callback-based approach for Discovery?
Cristiano: if we choose to have factory, we don't have to use the same interface for every start method
Zoltan: yes
Cristiano: I suggest having separate functions in a namespace
Daniel: I agree
Jan: also leaning towards Cristiano's approach
Zoltan: please make an alternative proposal, handling the generic discovery use case and also the async iterators fro multiple results
Jan: in implementation I found that merging the functions in one interface also has benefits
Zoltan: we should follow the rule of constituency: developers first, then implementation, then theoretical considerations
Daniel: we have 2 styles, we should choose the one simpler for developer
Zoltan: we might want to expose the initialization need for discovery
Cristiano: not sure if it's a real requirement
… we can split the init methods to the specific ones needed by the discovery method
Zoltan: I agree with with that
Zoltan: a bit concerned in exposing a lot of functions in the root namespace
Cristiano: yes, we can think about that
Kaz: we might want to survey the existing discovery APIs like Chrome Cast API, mdns-js and node-mdns. at least it would be better to have some kind of compatibility with them or some kind of binding.
Zoltan: we did that, but indeed we could do it again
Daniel: only direct discovery reports a single or no results, all the rest a list
Cristiano: those are not pure functions, e.g. local does different things than multicast
Cristiano: I met a problem as a developer with the too generic object approach - would have preferred separate functions
… the discovery spec is also designed for separate use cases
Daniel: to not have root level function spread, but we could put them into an object
Zoltan: let Jan and Cristiano comment on issue 364
… and let's continue the discussion in the issue, rather than in PRs
Cristiano: yes - and also need to think about the algorithms
Daniel: time is up, let's continue on github
Jan: I already opened a PR for node-wot, will update that with Cristiano's proposal and then we have an implementation viewpoint as well
Daniel: adjourned