Meeting minutes
Minutes
<kaz> May-13
Cristiano: Checked them look good
… minutes are approved
Update wiki info
Cristiano: WebExcoordinates are outdated
Cristiano: We use Zoom now
… should update the entry
Daniel: Do other groups have the same issue?
Cristiano: TD is updated
… let's use the same style as on TD wiki
<kaz> Mondays at 7am...
Kaz: BTW, we need to improve the Scripting API wiki further. Section "Mondays .."
… time should be updated.. or remove whole section
Daniel: Could just leave US Eastern time.. since all W3C entries are based on US Eastern
Kaz: Okay with either way
(We simply changed the section title to "Mondays at 7am US Eastern", and keep the content.)
PRs
Improve README
<cris> PR 553 - Improve README
Cristiano: I tried to improve readme
Cristiano: PR updates readme only
… DP updated template
… this is a follow-up
Cristiano: added a little explainer
Cristiano: Jan proposed changes
… okay with suggestion
Jan: Apart from my suggestion it looks good
Daniel: Looks good now
Cristiano: Okay,. let's merge PR 553
<kaz> (merged)
use references from specref instead local bibliography
PR 552 - chore: use references from specref instead local bibliography
Jan: Mostly editorial
… we had manually defined references
… replaced those provided by specref
… PR points to latest REC version
… binding to latest spec version
<kaz> diff
Jan: Rendered diff shouldn't show changes
Cristiano: We point to REC version ... what about latest published version
Jan: specref can also point to latest published version
Cristiano: Until we don't use anything "new" we should point to REC version
Daniel: +1
<kaz> E. References section from the diff
Cristiano: Once we use new features we need to keep that in mind
Cristiano: Okay, seems ready to be merged ..
Kaz: Do we want to make all the other spec editors follow this style?
… maybe check with others in main call
… we could send mail message to team-wot
Cristiano: Will do...
… merging PR 552
<kaz> (merged)
Add clarifications for discover method
PR 551 - Add clarifications for discover method
Jan: related to discover method
… discover can handle introduction and exploration phase
… I added URL parameter
Jan: Maybe we need another interfaces
… and as DP mentioned we need to reflect it in TS definition
<kaz> Issue 535 - Dedicated methods for DNS-SD, CoRE Link-Format discovery, and other approaches?
Cristiano: related with issue 535
… question is what do we want to hide w.r.t. introduction phase
… what about preferences
… e.g., just things from a given thing directory
… where do we set the bar
… URL provided means we should go with this directory
Cristiano: URL can be added to ThingFilter also
… do we have use-case for using own URL
Luca: 2 scenarios
… all the discovery the app wants to support are provided by operating system
… system takes care
… on the other hand ... situation that application/developer wants to specify
… bare discovery is fine (based on operating system) plus having interface with URL or so
… e.g. just running query on a specific interface is apart
Zoltan: Bigger context
… multiple devices using Bluetooth and other means
… servient provisioned
… we need to support developer choices
… e.g. choose mDNS if available
… we could use filters
… no filter -> any means
… with filter -> application/developer can choose
Zoltan: multistage discovery is yet another question
Cristiano: I think we are aligned
… we need some "magic" discovery ... without any configuration
… we can try to be open to extension like Luca suggested
… own discovery mechanism
… how can we support that?
… what if I want to use default .. but additionally tweak it a bit
… how can I know which discovery mechanism is available
… rename ThingFilter ... more like configuration
Zoltan: filter is not local only
Cristiano: remote filter depends on options
Zoltan: filter is software construct
… local filter and protocol filters should be in different method
… API should be generic
… suggest to collect use-cases
… and check how we can solve them in Scripting API
Kaz: Agree with Cristiano and Zoltan, andcan agree on the need for a possible method for Thing Discovery
… However, there are a variety of possible different methods for WoT Discovery
… Also there are two possibilities, (1) "URL" here means the one of the Thing itself or (2) the one of the Directory service
… So we need to get more use cases to see which case requires what kind of method
Luca: first ground work ... what is the API and what are the boundaries
… one part is actual discovery like mDNS
… other part is interface that can be configured
… "my" discovery process could be just querying a directory I know already
… "my" filtering process could just be filtering things
Cristiano: All ideas are relevant
… also like recursion of TD directory
… I think we need developer experience
… Jan worked on dart_wot
Cristiano: w.r.t. to PR .. text improvement is fine ...
… however, changing method should be postponed
Jan: Okay, will split the PR
Daniel: +1
<JKRhb> +1
Next meetings
Daniel: will be on vacation till end of June
Cristiano: Please ping me in one way or the other so that we know
<kaz> [adjourned]