Meeting minutes
minutes
dp: minutes looks fine
… any remarks?
<kaz> June-13
dp: minutes approved
… there is an issue when updating the wiki
… I'll check it offline
Quick updates
dp: anything?
… we should plan the pubblication
… it will happen when we feel there are sufficient changes
… maybe after we close the latest issues
PRs
PR 405
<kaz> PR 405 - feat!: add new Discovery Web IDL definitions
dp: did you discuss about this PR last time?
cris: it seems that is stalled too
… but Jan is not here
… last time we skipped it
dp: ok let's wait then
Issues
Issue 403
<kaz> Issue 403 - DataSchemaValue misaligned in TS definitions
dp: the problem is that webIDL does not allow recursive definitions
… therefore we cannot express the same thing of TS
… but the text is already restricting the values
cris: right
… the only thing left to do is to update the text to feel more normative. This means to move the list of possible values outside the paretentisis
issue 402
<kaz> Issue 402 - Emitting no data for events
dp: old issue
cris: right I simply group similar issues under the same agenda category
… what is the outcome of 402?
dp: it seems that we need a PR
issue 408
<kaz> Issue 408 - Do we need an EventHandler?
<kaz> Issue 407 - Incosistency in emit property changed
cris: I think it was incorrect to call the observeHandler by default
… in node-wot we are using readHandler
<kaz> WoT Scripting API Group Note - 8.13 The emitPropertyChange() method
dp: it is a little counterintuitive to call a readHandler on a observable only property
cris: might be an hidden logic
cris: I would like to gather developers feedback about wheater we need a dedicated handler for emitPropertyChange
dp: right
… node wot does not have a dedicated handler
cris: there's the problem that the observe Handlers are probably not called when somebody observe or unobserve
… we need to verify it
issue 408
<kaz> Issue 408 - Do we need an EventHandler?
cris: not sure about the purpose of EventHandler
dp: are you saying that the eventHandler is just a no operation proxy?
cris: exactly
<kaz> |WoT Scripting API Group Note - 8.13 The emitPropertyChange() method||
dp: there was an use case from TUM
… let me see if I can find the issue
Issue 409
<kaz> Issue 409 - Harmonize the exposing process
dp: currently you create the expose thing and then call expose and from there you can operate it
… the issue is why we need two steps
cris: it is more about type correctness
… it seems better also about practical usage and sanity checks
dp: it seems so
cris: with the proposal you can use the produceThing as template
… not sure if you need it
dp: me neither
… it looks like an improvement
… if we integrate this change we should publish a new document
cris: +1
<kaz> [adjourned]