Meeting minutes
Previous minutes
<dape> -> August-1
Daniel: Any objections to approving the minutes?
Minutes are approved
Quick Updates
Cancellations in August
<kaz> Cancellations on the WoT main wiki
Daniel: As mentioned in main call, we will have two cancellation in august
… no call on August 15 and 29, with one call inbetween on August 22
Cristiano: Can't join on the 22nd
Daniel: We can have a short call at this date
Next charter topics
<kaz> wot issue 978 - Goals and Deliverable Discussion for WoT WG 2023 Proposed Charter
Daniel: When it comes to rechartering, we need to think about the document type (note, rec, ...)
… dedicated issue in the scripting repo
… my feeling is that we should go for the Note track
Zoltan: I added a comment to the issue
… how about moving the Scripting API to the community group
… could be a proper specification with faster progress
… potential topics are management API, credentials, conformance classes
… not in favor of splitting up the document
Daniel: Note track can also include normative statements now
… would make it easy to switch tracks
… community group would not get any "official" W3C support
Cristiano: Integration into Community Group would also require a rechartering
Zoltan: What is the difference between this WoT CG and the one by Ben?
Cristiano: The other one focuses on protocols
Zoltan: Scripting API would not fit into that one
Kaz: I'm okay with any decision by the whole group
… however, we need to be careful about the definition of the document types
… and include the decision in the minutes
… we should be clear about the pros and cons of each document type
Daniel: There other potential topics, one concerns the support for the EXI profile
… there are aspects (like the queryactions op type) which are not supported by the Scripting API, therefore they are not supported by node-wot
… making it difficult for developers to support it
… we should keep this in mind
PRs
PR #423
<kaz> PR 423 - Remove eventHandler
Daniel: Created by Cristiano before the call
Cristiano: What I did here was removing the eventHandler
… developers should not have to implement it
… already included in node-wot, however
Cristiano: Minor change regarding the potential event sources, the mentioning of the underlying platform has been removed
Zoltan: Asked a question in issue 408 if the EventHandler is needed
… if it is not needed then we can remove it
Cristiano: The use case for it is not there yet
Zoltan: Then I support removing it
Daniel: I agree, if there is no use case for having an EventHandler, then we don't need it
… overcomplicates things
Cristiano: We could merge the PR but leave the issue open for potential further discussion
Zoltan: We should record the discussion in the issue, justifying the PR
… the respective comment in the PR should also be reformulated in a concise way
Daniel: (Adds a comment to issue #408)
Cristiano: There is an open comment regarding a "void" data payload
… could be reformulated, didn't use undefined because it is a Javascript concept
Daniel: Couldn't we say "no payload"?
Cristiano: Some protocols have payloads with no content
… we could avoid using void, however
Daniel: We will wait for the improvement of the PR
… will also check the rest
PR #424
<kaz> PR 424 - Fix internal slots
Cristiano: Marked it as draft for now just to inform you about a potential issue
… I noticed a number of missing references in the document
… for example, in the ExposedThing section
… there we now have a correct reference that was not working before
… this was fixed by adding brackets
… this now causes the problem that there are missing descriptions for internal slots
… will be included in the PR later
… internal slots now also offer context menus listing references
… should also be done for the ExposedThing
Daniel: There is a difference in the node-wot implementation regarding activeSubscriptions and activeObservations in node-wot at the moment
Zoltan: PR looks good, I already approved it. The remaining internal slots should be mentioned as well
Cristiano: Problem is that we have complex internal slots
… does it work to add these to the list?
Zoltan: As they are dynamic, we should remove them
Cristiano: There is also currently an error regarding activeSubscriptions and activeObservations, as they are not part of the ConsumedThing but of the Event/Property
Zoltan: There might also be a different solution to internal slots. Question would be if we can describe the algorithms without internal slots
Cristiano: They make describing the algorithms easier. An alternative would be to use a map instead of a set here
Issues
Issue #417
<kaz> Issue 417 - emitPropertyChange does not take low-level event apis into account
Daniel: This issue is by Ege
… there was some discussion about what is actually meant by the issue
Ege: Current API currently reads values twice
Zoltan: With the current API, another read should not be necessary
Ege: I can give a more detailed example in code
… the current API design implies that you need to read again on a property change
Kaz: Regarding this issue, I would like to hear from Ege some more detail about the expected use case and scenario, rather than the data model and API
… it should be clarified what should be done in certain situations
Ege: My use case is that I have, for example, a sensor or a robot arm, which changes state and would then emit a property change (rather than an event)
… question is how to deal with such changes and how to define with low-level changes
Cristiano: I am starting to see the use case, question is how much complexity is introduced by the current API and how to keep consistency between reading and observing property
Zoltan: I wonder if this is about implementation optimization or API design
… implementation feedback is important, however, we need to take feedback into account
Ege: I will provide a code example
… an exposer thing implementation
… with well-defined or safe behavior
… accessing the property twice should slow down the implementation only slightly, though
Cristiano: Returning the cached value would not trigger read twice
Daniel: Let's move on based on Ege's example
… next call will be on the 22nd
[adjourned]