<scribe> scribe: zkis

Guest

Jacob Weigand is a guest from TUM today, and aware of the W3C Patent Policy

PRs

PR 246, https://github.com/w3c/wot-scripting-api/pull/246

Zoltan: w3cid to be completed, please add a commit

Cristiano: will do

PR239, https://github.com/w3c/wot-scripting-api/pull/239

Cristiano: went through the doc for corrections
... a major modification is adding the writeAllProperties() method
... also, changed an algorithm name

Zoltan: I agree with the algorithm name

Daniel: a comment about writeAll: would not spend too much time on that since it's going to go away
... in the TD spec

Zoltan: do we know what is in the writeAll Form, since the algorithm might depend on that?
... what about moving the writeAll commit to a branch and wait for the TD spec?

Cristiano: we could do that

Daniel: we could do everything with writeMultiple

Cristiano: though that it was writeMultiple will go away

Daniel: maybe we will need writeAll in the future, but I also think we should wait with adding writeAll

Cristiano: we could add an editor's note why don't we have it

Zoltan: right

Daniel: and say we could use just writeMultiple

Zoltan: ok, so these PRs will get changes and then merges

issue # 237

<dape> https://github.com/w3c/wot-scripting-api/issues/237

<inserted> Scripting API draft - D. Full Web IDL

Jacob: Ege asked to make a demo with the problem
... MQTT cannot communicate an error in the subscription
... when the server is dropping, the Scripting API does not provide an error in the subscription
... the next subscribe request should fail
... same with longpoll
... there is also a race condition

Zoltan: we have 2 options: a separate object for a subscription with an error event, or put the error event on ConsumedThing

Cristiano: would prefer the first

Daniel: we could have a generic error (call?)
... or an object that can point to new errors

Ege: we need to know which the subscription the error belonged

Cristiano: right, which is why prefer the first option

Daniel: a generic error listener also means the client has to filter (also mentioned by Ege)

Zoltan: so we could revert to a kind of Observable

Jacob: I thought about adding an error listener to the observe() and subscribe()

Daniel: I see benefit in managing it with a subscribe object since we shift complexity
... the implementation tracks subscriptions automatically

Zoltan: Kaz, what was the deadline for publication in last WG call? end of September?

Daniel: I thought it was beginning of September

Zoltan: we have a lot of changes, we could also make 2 publications

Daniel: we should make less publications since implementations need to change
... node-wot would wait for the revised API

Kaz: publication time is based on the TF decision
... could be done quickly or we can wait for another update and publish the document a bit later

Zoltan: we should go by DP's proposal and adjust the publication date

Kaz: please note that Scripting API is a WG Note for the current Charter

Zoltan: what about versioning the Scripting API itself

Daniel: not sure will it be a URL or a version string

Zoltan: do we have a need for an interface file def with a given version as a package dependency?

Ege: for what use case, for telling old or new APIs apart?

<Ege> https://github.com/eclipse/thingweb.node-wot/tree/master/examples/templates/exposed-thing#change-from-version-06x-to-07x-for-exposed-things

Zoltan: node-wot defines a version and also refers to the Scripting API spec it implements

Daniel: it defines a version right now, it includes TS definitions that are also published on npm

Zoltan: anyway it's doable to include the TR link for Scripting from node-wot
... we need a label that we can easily connect the two

Cristiano: I agree, like node-wot is implementing the 0.8 API spec.
... another issue is that in TS we can add links back to definitions

Zoltan: makes sense

Daniel: the problem is that if you update the spec we need the permalinks

issue #244

Zoltan: there is validation for consume() and not for the construction

Cristiano: it should be the other way around

Zoltan: constructor is just a JS object constructor
... validation needs a factory method

Cristiano: validation could be done synchronously

Daniel: consume() and constructor should do the same

Zoltan: looks like that is possible
... ok, so let's change the issue name and track it there

Daniel: we have similar issue for produce()

Zoltan: let's continue the discussion next time

Ege: a quick question, for reviewing created a fork and empty branch, should I make the PR in the Scripting?

Zoltan: AOB

adjourned