Meeting minutes
previous minutes
<dape> Feb-21
no objections
minutes approved
quick updates
Daniel: on the main call it was asked when Scripting TF will update the spec
Daniel: it depends on the other publications; TD is stable, others maybe not
<cris> +1
Daniel: we could wait a few weeks that the dependent specs are updated
Daniel: currently the main dependency is Discovery
PRs
PR 386
<dape> PR 386 - refactor: remove obsolete package-lock.json files in sub-directories
Daniel: there is a stalled PR (dependent on discovery) and the obsolete package lock (link above)
issues
issue 376
<dape> 376 - Check alignments with Architecture
Daniel: the discussion converged on text aligned with the conformance classes
Daniel: any objections?
Daniel: will prepare the PR for Architecture
issue 384
<dape> Issue 384 - Align discovery and scripting
Daniel: there is a related PR in Discovery
Cristiano: establish minimal requirement for client in order to be able to discover
… now it includes HTTPS
Daniel: the work should continue beyond HTTP
… in Scripting we'll have the same restriction
Cristiano: yes, the discovery conformance class must implement HTTPS
Zoltan: it doesn't change the API shape, but it has to be clear in the spec, for implementations
Daniel: there was also a pagination that only worked in HTTP
… was that the reason why HTTP is mandatory?
Zoltan: did they study the CoAP discovery, e.g. in OCF - that is a very clear mechanism
Cristiano: yes, it was considered
Daniel: do we know when they plan to converge on this?
Cristiano: the deadline is close, but is not known (it's being shifted)
Zoltan: this is not a strong dependency for Scripting, only for implementations (node-wot)
Cristiano: there is the issue why Scripting allows using the Fetch API
Zoltan: Scripting discovery API may use also other architectural solutions for discovery than the one described in the Discovery spec
Conformance section necessity
<dape> Issue 354 - Conformance section necessity
Daniel: the chairs need to send an email to the AC reps participating in the WG
<dape> https://
Daniel: since Notes are not covered by W3C patent policy, so it needs to be agree within the WG
Kaz: we need to think about how to deal with normative sections in Notes, but we might also put the Scripting API back to the REC track in the next charter
Daniel: one doesn't exclude the other in my opinion
Zoltan: the point was that ML didn't consider this side-agreement a clean solution
… it would be cleaner to be regulated by the W3C process
Kaz: let's check with the chairs about the progress
Daniel: OK, so let's keep this open
New op values (queryaction and cancelaction)
<dape>
Daniel: in the TD spec the PR was merged which introduced the new op values
<dape> https://
Daniel: we might need to change the API, e.g. invokeAction()
Cristiano: we can query only one instance of an action
Daniel: my assumption was that we need to know the action instance in order to be able to later interact with it
… so we cannot just add 2 new methods like queryAction() and cancelAction()
Cristiano: so we need to change the return value
Zoltan: can we identify action instances on the wire (i.e. protocol binding dependent)?
Daniel: that was my assumption
Cristiano: it's quite difficult to specify an algorithm to handle action instances
… if the TD doesn't define this well
Daniel: we need to check if it's not well defined
Cristiano: in the last plugfest we experimented with this
Cristiano: if an invokeAction() returns a JSON, how can we fake that as a control object?
… it will be complex
Zoltan: we can define an action control object that has a callback (event) for completion, returning InteractionOutput, and one method for querying
Cristiano: what if different things will return different results for the same action?
Zoltan: I still think we could do a control object that will work
… I could draft a few alternatives in the issue, and when we have consensus, we can decide and make a PR
Daniel: yes, and as CA mentioned, we should check the TD spec completeness as well
Daniel: we can also query (and cancel?) all actions
Cristiano: the feature is in risk because no implementations yet
Daniel: sooner or later there will be implementations, even for Profiles
… but if no one implements these, then it's out of the game
Cristiano: the Things gateway implements this on protocol level
Zoltan: I think it would make even more sense to support cancel all actions, than query all actions
… we need to wait until this is clarified, since it will change the API shape
Daniel: I will take a look at that
Daniel: Ben had a use case for querying all actions
Zoltan: looks like network optimization, makes sense
Daniel: we need to adjourn
adjourned