<scribe> scribe: zkis
Zoltan: propose to make a Note from the current version and then if we change the Discovery API, we can make another Note
Daniel: does the Discovery TF has deadlines?
Kaz: we can talk about that in the Discovery call today
<kaz> June 15
https://github.com/w3c/wot-scripting-api/pulls?q=is%3Apr+is%3Aclosed
Minutes approved
<dape> Issue 222 - Possible alternative design of Discovering API
Cristiano: presents the proposal
Zoltan: explains his own comment in the issue
Cristiano: completely agree, need to converge on a stable set of discovery methods
Daniel: we should keep the API
similar across the 3 patterns (consume, produce,
discover)
... for instance if we look at DataSchema abstract class +
subclasses, we could use something similar eventually
<kaz> 9.3 The ThingFilter dictionary
Daniel: we could have an abstract ThingFilter and then different instances
Zoltan: that makes sense
Cristiano: I see the point, but it's not
trivial to use a common ThingFilter across all methods
etc
... are you proposing different methods or not?
Daniel: I can add a comment to the issue
Cristiano: if we have one method with
different subclasses of ThingFilter, then we implement
different strategies with different classes
... it's better to use functions
... but we need more experimenting and more inputs
... looks there is consensus there will be 2-phase discovery,
and this should also reflect in the API design
Zoltan: 2-phase is a newer development, we will follow the discussion
Daniel: not opposed to the proposal,
but seen the similarity with DataSchema
... one open point: we usually in plugfests we didn't use
discovery, grabbed the TD URL from somewhere, so we should
implement discovery in node-wot
... we did have some early implementation, but the number of
options for URL complicates things
Zoltan: we could use some kind of capability querying API for discovery
Zoltan: any resolution on that in the TD call?
Daniel: no resolution yet, looks like an optimization
<kaz> wot-thing-description issue 848
Daniel: we could mark it deprecated and not support in Scripting
Cristiano: I remember the same, people were more supportive of reading all properties
Kaz: I also asked everyone to have more use cases for this (during the TD call)
Zoltan: we should be able to deprecate things, so what about putting version number in WoT object?
Cristiano: sounds fine
Daniel: node-wot is not fully compliant with TD spec on handling readmultiple
<kaz> 7.6 The readMultipleProperties() method
Daniel: we should perhaps drop it
Zoltan: right, we can add it back
later
... will make an issue about this
... should we publish before we remove?
... let's think about that until the next call
Cristiano: needs more discussion
Daniel: BTW, does WebIDL support modules?
Cristiano: yes, modules should represent namespaces
Cristiano: we reached a consensus about
the flow support
... propose to discuss this next time
... including the lifecycle of the script itself (e.g. waiting
for user input)
Zoltan: it should be abstracted by the UA behind async operations
Cristiano: currently we cannot trigger a flow
Zoltan: we used to have a start() call for that, but we removed it
Daniel: in node-wot we have basic support for that
<kaz> [adjourned]