Meeting minutes
Minutes
approved
PRs
Daniel: two PRs there
… any opinions?
… would skip them given lack of participation
ok
Issues
Issue 409
Issue 409 - Harmonize the exposing process
Daniel: may need another publication
… regarding the "ExposedThing" interface
… proposal on two-step approach
… ProduceThing and then ExposedThing
… but this is a breaking change
Daniel: looks good to me, though
… makes a lot of sense
Kaz: from my viewpoint, this is related to programming language mechanism
… objective programming languages support constructor/destructor mechanism
… and "ProduceThing" should be handled by that mechanism instead of our own defining a new method
… so it would have impacts for the existing implementations
Daniel: right
… so it's a breaking change
Kaz: so I'm wondering if it's possible for us to get some more support from the JavaScript programming environment and existing libraries
Daniel: good question
Cristiano: JavaScript supports objective programming
… but normal constructor is not enough for productThing
Daniel: exposing, consuming, and discovery
Cristiano: network/filesystem handling capability
Kaz: if we really need it, we should go for that
Daniel: not *needed* but it would be clearer to see what to be called when if we had it
Kaz: making the mechanism clearer is a possible "need" for the change
… but we should be careful about the need
… and possible impacts for the existing implementations
Daniel: yeah, it would have impact to implementers
Kaz: also need a possible DeleteThing in pare with this ProducedThing?
Daniel: note that the method itself, ProducedThing is not added
… but on of the sub methods, etPartialThingDscription() will be added
Kaz: ok
ack
… what about expose()?
… changing from the type from void to returning something?
Daniel: yes
Kaz: if we add the "getPartialThingDescription(), who would validate it and what would happen if any errors?
Cristiano: good question
… should be validated beforehand
Daniel: should change the return type to "ExposedThingInit"?
Kaz: it sounds a bit dangerous to me to apply this change to the Scripting API spec directly
… so would suggest we see the potential impact based on some specific use case scenario after adding a change as a trial
Cristiano: agree
Daniel: yeah
… should get further feedback and comments
… would see Jan's opinion as well
Issue 403
Issue 403 - DataSchemaValue misaligned in TS definitions
Daniel: relates to another issue 296
Issue 296 - DataSchemaValue in TS should not be any
Daniel: it was impossible to handle the details by WebIDL
… so we wanted to use Typescript instead
… maybe we might want to revisit that approach as well
… would suggest we once close this Issue 403 itself
Daniel: (adds a comment to Issue 403)
… we should move parenthesized text out
Issue 408
Issue 408 - Do we need an EventHandler?
Daniel: need for a dedicated Event Handler?
… got a comment from Ege
Daniel: (shoes the example code within Cristiano's comment)
var produced; // Produced Thing
produced.setEventHandler("noDataEvent", () => undefined);
/ exposing
await produced.expose();
produced.emitEvent("noDataEvent");
Cristiano: a picture would be helpful
Kaz: agree system configuration figure and communication diagram would be helpful
… also we should clarify what kind of entities to be included how for what kind of use case scenario as well
Daniel: yeah
… would invite Ege to join the Scripting call too
… thought there was a related PR as well
PR 218 - Add ExposedThing property observe, unobserve and event handler support
Daniel: but that includes too many changes...
Issue 407
Issue 407 - Incosistency in emit property changed
Cristiano: for node-wot, we don't call eventHandler but call readHander directly
Daniel: (shows 8.13 emitPropertyChange() from the published Note)
8.13 The emitPropertyChange() method
Cristiano: could use emitPropertyChange(), etc. if needed.
Daniel: we could use the same handler unless there is a specific need/use case
… will propose a PR
… would get feedback from others too
[adjourned]