Meeting minutes
Previous minutes
<dape> -> May-16
The group goes over the minutes and discusses the minutes
Daniel: Minutes look good, we can publish them
Quick Updates
Daniel: Can be skipped
… we will publish a new WD, once the discovery question has been resolved
PRs
PR #404
<kaz> PR 404 - fix: add missing emitPropertyChange() method
Daniel: PR is about a missing emitPropertyChange method on the ExposedInterface
… PR is already merged, changes are published on npm
PR #405
<kaz> PR 405 - feat!: add new Discovery Web IDL definitions
Daniel: PR contains a WebIDL proposal for a new discovery API
Jan: Still WIP, based on an issue with concrete code examples
… we can discuss the PR based on the issue
Issues
Issue #364
<kaz> Issue 364 - Using a callback-based approach for Discovery?
Daniel: In your proposal, fields are mandatory
Jan: With the code examples, I got the impression that these fields should be mandatory, but this change can be reverted
Zoltan: We need to discuss the algorithms
… making parameters mandatory changes the allowed behavior, local discovery would not be possible with mandatory ones
Cristiano: Issue touches a different topic, general shape of the API, parameters are second step
( discussion on Jan's comments: https://
kaz: I'm wondering which would be better to include this change into the Scripting API at the moment (=during this Charter period) or not
Zoltan: it would make the API simpler
… and we could get feedback
Cristiano: could be included in ver. 1.1
… but can be deferred to the next version
… we're not changing the target use cases
Zoltan: we need feedback from the Discovery TF
… also implementation feedback as well
… from my viewpoint, this is just a small syntactic change
… once the PR is approved, we need to think about an updated algorithm as well
Daniel: I'm also a bit unsure
… you could still use the old API
Zoltan: that's true
… would need to implement the "next" method
Jan: right
… can update the example too
Daniel: Jan is also proposing renewed algorithm for node-wot too
Zoltan: people could use both the methods, the current design and the new one
… and see which would be better
… think it would be make it more portable if we use the new "next" method
… it's a more modern approach
Daniel: ok, tx for your proposal, Jan
Issue 403
Issue 403 - DataSchemaValue misaligned in TS definitions
Cristiano: need some more discussion
… didn't have time to create a PR, sorry
Issue 402
Issue 402 - Emitting no data for events
Cristiano: Current dataschema does not really allow for emitting no value at the moment
… question whether we should align WebIDL and typescript definitions, restricting the type of DataSchemaValue to a set of values instead of any
… this is currently the case in typescript
Zoltan: We discussed this earlier and we made a decision for a reason
… however, the API should be clear about what is optional or not
… I am not sure if we can define DataSchemaValue as a value other than any, but making it optional would be possible
Daniel: Could we run into problems due to the recursive definition for Arrays?
Zoltan: Recursive values are illegal in WebIDL
… algorithms need to be specified to handle recursive data structures, syntactically they cannot be defined in WebIDL, however
Cristiano: We might already be aligned with the typescript definitions via the specification's prose
Daniel: Issue 402 has a simple solution, adding the optional keyword to the parameter
Cristiano: ... and updating the algorithm
Cristiano: There was also an issue regarding returning no value from actions
… but it was in the TD repository?
Daniel: (Looks for the issue (#1234) and finds it)
… the problem is not the same, though
[adjourned]