<scribe> scribenick: dsr

<scribe> scribe: Dave_Raggett

<jhund> https://github.com/zolkis/wot/blob/master/proposals/restructured-scripting-api/intel-proposal.md

Zoltan presents his scripting API proposal

He starts with discovery. He has updated the issues and is seeking feedback.

He had a version with observers, but these aren’t ready yet

The existing proposal uses a promise and returns an array

You can’t normally wait until the array is fully populated and instead need a mechanism that reports things as they are discovered

This suggests a call back/eventing mechanism

Johannes: we discussed some ideas for this, e.g. something like observers

Zoltan: observers are a design pattern for a series of notifications from ECMA TC39
... for JavaScript

For now we can stick with an existing solution, and plan to support JavaScript observers once they are widely supported

Johannes: we could use something like setInterval so that you can cancel the notifications

We would need a means to inititate and to cancel the notifications for discovery

Dave: why not use regular events with filters and live arrays as in Mac OS?

Zoltan: we can’t use filters with events.

Dave: why not? We are free to define the API for subscribing to events. We could define a filter as static data, or as a call back.

Zoltan: I am not against it if we can do it

Dave: anyone prepared to comment on live arrays?

Johannes: it is a bit abstract and I would like to see an example

Dave: it is used by Apple for zeroconf with mDNS

Kaz: the W3C Multimodal Interaction WG have been working on discovery, and I would like to invite their suggestions

Johannes: okay
... perhaps Dave could provide further details in email

Zoltan moves on to discuss his consumedThing API

This has several operations inspired by REST

(presumably consumed thing is the API for a client of a thing)

ExposedThing is the corresponding API for scripts that are publishing a thing.

Zoltan walks us through the register and unregister operations

Both the consumed and exposed thing APIs are compatible with REST protocols

Johannes: so far we have things with properties, actions and events. I am unsure how your proposal maps to that model?

Zoltan: my proposal maps to the whole thing

Johannes: so you could use a PATCH operation to update properties?

Zoltan: yes

Johannes: your proposal is similar to what we have already discussed, but is somewhat lower level, e.g. with CRUDN operations

Zoltan: … how do you have a tree of things …

Johannes: consider how to set an observer for a single property, how would you support that?

Zoltan: an ECMAScript observer

Johannes: Dave talks about proxy chains

We should discuss the different approaches and where it makes sense to combine them

Zoltan: yes, for that we need the use cases

k_nimura: we need to separate the client and server APIs
... especially for a tree of proxies

Zoltan: we do allow for that having both the client APIs and the server APIs

Johannes: it could be that constrained nodes only support a subset of the APIs

One example, is the means to add properties dynamically at run time

We may want a means to check what capabilities a given server supports.

k_nimura: we need rich capabilities for the cloud

Zoltan: we could have an API for when the model changes

Johannes: I am working on a demo for this with dynamic things, e.g. adding and removing properties. I will provide a pointer when it is further along

Not every runtime needs to support the disovery API

Zoltan: each thing would provide access to what capabilties it supports

In OCF these are referred to as “interfaces”

Zoltan: this is also related to access control. However, I am not sure how general it is across different protocols

k_nimura: is there a lifecycle document available from the OCF?

Zoltan: the interfaces are defined statically in advance

k_nimura: if you think about tree structure, you may want to consider a dynamic API, but it isn’t there in OCF right now?

Zoltan: no it is not

Kaz: so we plan to consider adding a capabilties mechanism to the current practices based on today's discussion?

what are the next steps?

Johannes: my view is that we have an overlap with what OCF is doing, however, we also see differences, I think we should review the use cases and then decide how to proceed in respect to the next plugfest

<kaz> s/a capabilities mechanism/some more mechanism, e.g., server capability,/

We only have a few months before the next plugfest, so we need to progress quickly

but note that it is very open to comments

Zoltan: the web of things emphasises data models, and that is not so much the case for the OCF APIs, but we should look at the use cases

we don’t know enough to converge on the scriptin APIs right now

k_nimura: if we want to merge the specs, is the intention to automatically support OCF devices?

Zoltan provides some further background

Zoltan: e.g. in the context of dynamic models, that should be worked out at W3C

Johannes: are there any implementations we can look at?

Zoltan: Michael Koster has one based upon the OCF REST server

Johannes: so we need to consider the use cases over the next month to drive the discussion along with appropriate examples

It would be good to include some OCF devices in the plugfest

Zoltan: that would be a good idea

Johannes brings the meeting to a close and thanks Zoltan for his contributions

Zoltan will update his proposal and provide a pull request

Johannes: lets look forward to discussion on combining APIs.

Others are invited to also put together some proposals fo future calls.

scribe: , end of meeting …