Meeting minutes
Previous minutes
Cristiano: no meeting
Quick updates
Co-Moderation
PROPOSAL: Cristiano being the co-moderator of the scripting call. Will be announced in main call.
RESOLUTION: Cristiano being the co-moderator of the scripting call. Will be announced in main call.
PRs
PR#424
Cristiano: Updated notation for internal slots
… PR ready for review
… with latest respec configuration
… citing now uses proper definition
… ConsumedThing references are complete
… node-wot follow the same structure
… for ExposedThing ... some internal slots are missing
… for property internal slot has been added
… some todos
… internal slot for events
… check "subscribers" internal slot
Daniel: Shall we wait for the todos to be done in this pr?
Cristiano: Suggest to add todos in another pr
Daniel: Makes sense, will review after this call
Cristiano: OK, changed PR ready for review
<cris_> https://
PR#441
<kaz> PR 441 - Align the discovery API with the Discovery spec
Cristiano: Gave review
… still need to check your comments
… propose to split one text in 2 different cases
… added another comment
Zoltan: pushed commit to split into 2 cases
… btw, filter is not supported
Cristiano: I think this resolves my first comment
… w.r.t. the 2 comment... I suggest to be more explicit
Zoltan: What about the other errors
… need to be more specific for other places as well
Cristiano: Could do the same as for fetching TD
Zoltan: If we go into those details.. we need to add a lot of details
Cristiano: I see
… maybe adding some explanation text might help
Zoltan: We need algorithm for fetching TDs
… not sure how to link it to protocol bindings
Cristiano: I guess we can resolve this comment also
Zoltan: Suggest to open new issue
Daniel: Should discuss this in new issue... but there are different uri schemes .. and many errors and such might pop up
Cristiano: I see
Zoltan: BTW, there is a complete spec that defines fetch...
… TAG might raise issues
Cristiano: I would point to protocol bindings ..
… anyhow, the PR looks good
… and I think we can merge... any concerns?
… -> none -> let's merge
PR#442
<cris_> PR 442 - fix: emitEvent() method allows data to be optional
Cristiano: Seems fixed and ready to be merged
… Zoltan approved also
… PR fixes issue with describing no data in event
… Daniel also updated TS definitions
Daniel: related to issue 445
Cristiano: Okay for merging?
… no concerns .. merging
Issue
Issue#417
<cris_> Issue 417 - emitPropertyChange does not take low-level event apis into account
Cristiano: Issue was opened by Ege
… he spotted some issue in new design
… added use-case description
… I responded to the use case
… from low level api point of view
… low level can offer different api
… 2 cases
… a) by listening to events
… b) polling
… the new design of emitPropertyCange
… we force to use read handler for property
Zoltan: might mean 2 rounds in implementation
Ege: not exactly for events/properties
… e.g., streaming value with property
… one needs to cache value
Cristiano: Not sure why get operation is needed
… you have already the correct value
Ege: IF I detect a change.. I want to send update
… interacts with sensor twice
Zoltan: Talking about implementations?
Cristiano: with cached values no second interaction is done
… some people might use a different approach..
Kaz: Meta question: Do we have concrete description of expected protocols?
… if we have enough knowledge we can think about the details
… 2 options
… give up for now
… or narrow the scope (some potential use-cases)
Cristiano: We have clear view of use case
… hard w.r.t. technology
… probably we need to study more libraries
Zoltan: Fear race conditions
… suggest to keep this issue open
Ege: I can have another look and provide more feedback
… in the end the current proposal is fine
… we just need to make developers aware of it
Zoltan: we do not guarantee that value is latest value
Kaz: we should look into popular methods in OPCUA, ECHONET, ...
… we can borrow their ideas
Cristiano: Agree
[adjourned]