<kaz> scribenick: zkis

jhund: 2 main topics: architecture, WoT runtime, scripts model
... 2 open pull requests
... open issues

<inserted> scribenick: kaz

Issue 2

<jhund> Issue 2

<kaz> Pull request 21

discussion on remote things vs local things

creating things locally/remotely depends on the things: description

rest interface to expose the things: capability

we'll need some kind of management capability?

need to define protocols

but it's up to bindings

we don't need to expose scripting API level

concrete protocols depend on underlying implementations

runtime has multiple event loops?

if we agree it's OK to let multiple scripts in parallel that would be possible

zkis: who would access which device?

dsr: I'm using node.js
... I have an application folder
... could be done for runtime or initial startup phase
... modularity with each script
... with some specific namespace
... authentication data access
... our security TF is a bit behind

zkis: what kind of mechanism is implemented in things?
... what is the use case?
... modifying existing exposed things, etc.?

jhund: we've implemented what Dave mentioned
... run on the same event loop
... however, "Things" could represent devices

zkis: we're doing similar things...
... but seems a bit different from the Scripting APIs

jhund: you could do the same by adding something to the WoT object

zkis: that's called action

jhund: how to let the runtime run the script?
... mentions the voting use case
... running within a specific runtime?
... or several scripts working together

zkis: you can add actions
... and run them later

juhd: how to handle them?

zkis: dictionary for action definitions?
... serialized by the binding capability

jhund: interesting to consider how multiple voter work together
... actions from voters
... vote goes up

zkis: we have to discuss security

dsr: simpler concept would be better

kaz: maybe we could start with a simple example with only 2 voters

jhund: runtime A vs runtime B
... (shows some example script)

example script

jhund: would put ideas on the "whiteboard"
... having 2 runtimes
... red one (A) and blue one (B)

zkis: sounds like a definition of a "Thing"
... we're missing one more capability
... "modifying things" capability
... if you want to use/modify some "Thing", you can add an additional action

dsr: access control between A and B
... management API
... so we need some basic management capability
... how to avoid conflict?

<dsr> Dave: it sounds like we need a remote management interface to install, start and stop things. This needs the appropriate security model.

<dsr> Separately, we need to consider how to resolve conflicts e.g. when several clients have conflicting updates on a thing

jhund: do I have the right for A or does B have the right?
... when I want to create a new Thing

zkis: you control B's description
... A can change anything
... A has to resolve conflicts
... B is just a runtime
... A is a temporary thing
... channels depend on underlying mechanism

kaz: (adds "Device" to the right below box, "Servient" to the right above box, and "Browser or Heating" to the left box)
... should only the Servient B handle the resource/conflict?
... or do we want to have a separate/additional resource manager?

zkis: depends on the underlying framework

nimura: Browser A also needs some kind of resource management capability
... to check security

jhund: clear need for management interface
... when we create exposed thing
... whether it's local or remotely accessibly
... why don't we reuse the mechanism for local servient
... for remote servient

zkis: right

kaz: what's the difference between "local" and "remote"?
... do we need to think about the difference?

jhund: A is local
... B is remote
... in this example
... we need to think about binding, security questions, ...

zkis: can create pull requests

uday: can we use resource directory?
... interface to access
... A is trying to access B
... there could be some authentication mechanism
... e.g., time limited authentication
... local resource directory

zkis: you mean B can store local directory?

uday: yes

zkis: that's possible
... but Scripting API itself doesn't care about it

jhund: how to map this using protocol binding?
... resource directory or TD directory
... what would be needed from the Scripting API viewpoint?
... I'd ask Zoltan and others to provide ideas. I'm also happy to contribute

zkis: would update the rational document
... possible global management capability
... and how this would be mapped, etc.

jhund: will tidy up the diagram
... we identified two issues today
... let's switch over to pull requests

zkis: let's take your pull request first

Issue 18

Issue 18

jhund: some use cases for writable to ThingProperty

pull request 20

WebIDL spec

jhund: adding readOnly entry for Property initializer

zkis: consumedThing should be readonly by default

jhund: readonly vs writable
... exposedThing could be writable
... will make the property "writable" and make the default value "false"

zkis: according to ECMA
... "writeable"

jhund: ok to use "writeable"?

(ok)

jhund: will merge in this

Issue 17

Issue 17

zkis: related 3 issues: 2, 5, 16

<zkis> https://zolkis.github.io/wot-scripting-api/#terminology-and-conventions (Zoltan's proposal)

jhund: name for referring Things
... possible different ways for discovery
... "local" is type of filter
... we got collection of use cases
... different types of discovery

zkis: we can discuss the detail during the next call

jhund: yes
... and we might want to invite discovery guys, e.g., Soumya and Louay
... can take an action for that
... comments?

zkis: put a note

[[
Note that canceling a discovery (through unsubscribe) may not be successful in all cases, for instance when discovery is based on open ended broadcast requests. However, once unsubscribe() has been called, implementations must suppress further event handling ( i.e. further discoveries and errors) on the Observable. Also, a discovery error may not mean the end of the discovery process. However, in order to respect Observable semantics (error always terminates processing), implementations must close or suppress further event handling on the Observable.
]]

jhund: sounds good
... looks at the example and IDL
... makes sense

zkis: canceling discovery through unsubscribe may not be successful, e.g., by timeout

Issue 14

Issue 14

jhund: exposedThing and DynamicThing
... this policy would make sense

zkis: ExposedThing is always modifiable

(official call ends)

some more discussion by Johannes and Zoltan