<scribe> scribenick: dsr

Johannes introduces the agenda for today’s call.

Johannes invites Zoltan to introduce his topic.

Zoltan: it is incomplete and needs feedback.

Johannes: let’s discuss it today, and we can merge the pull request when you’re ready

Zoltan: I need to do a few more edits before I think it’s ready for merging

We should discuss the use cases before merging

<jhund> https://github.com/w3c/wot/pull/282

Daniel asks how we could relate Zoltan’s document and the older document on use cases?

Johannes: Zoltan’s is specific to scripting APIs

Zoltan: yes, indeed, it focuses on requirements for the scripting API

Daniel: we no longer have an editor for the older document, but we need to consider how to proceed with work on use cases

Zoltan: you could merge the pull request right away if that makes it easier for the group to provide feedback

(as compared with the diff format of the pull request)

Johannes: any objections [no]

See https://github.com/w3c/wot/blob/master/scripting/use-cases/README.md

Johannes: please read and comment

Many thanks to Zoltan for providing this

Johannes: I would like to discuss two issues.

<kaz> Issue 240

There was discussion about the use of Promises versus providing call backs versus the use of EventEmitter/EventTarget, and the upcoming ECMAScript observables.

<kaz> Issue 235

We have heard arguments around these alternatives. NodeJS is built around EventEmitter.

Johannes: we need a decision and would like to hear opinions

Dave: is this for the next Plugfest?
... we can’t bind the hands of the WG, but we can document our discusion, and our experience

Zoltan: I suggest we discuss this when we merge the API proposals. On the server side we tend to use call backs

We don’t know enough to commit to one of the choices right now

The Sensor API spec used EventTarget as they want to get to REC very soon.

Johannes: so the suggestion is to gather use cases now and defer a decision

Daniel: I agree with gathering feedback, but we should also seek feedback from external experts

For instance what is most comfortable for developers, perhaps via a questionnaire

We need to pick a solution for the next Plugfest, but we should aim to invite feedback from implementers on the range of solutions

More complex use cases are likely to provide better information

Kaz: If we want to gather feedback perhaps we need a dedicated wiki page or GitHub page? We should perhaps decide on some advanced use cases for the Plugfest.

My second comment is on the decision procedure. The WG isn’t yet operational, so the discussion now is for the IG’s plans. On the other hand, once the WG is launched, we need to think about which part of the discussion should be done by the IG side and which part should be done by the WG side.

Daniel: there is an open issue for language neutral descriptions of APIs and this is also relevant here. Let’s review which features are supported by different languages.

Johannes: my intention here is to encourage implementation feedback at the Plugfest

Zoltan: on the client we’ve used EventEmitter and callbacks on the server

We’ve explored the association of events with groups

We should discuss this further

Johannes: some people worry about the feasibility of JavaScript on small devices, so making it sense to support languages used on embedded systems.

Recent work suggests that JavaScript can work for quite small devices

We should look at use cases and gather requirements at a language independent level

Zoltan: we have experience with JavaScript on small devices. We need to work with manufacturers on ideas for native support for scripting

Uday: We should include use cases that cover constrained devices

we should also consider the architecture document

Johannes: I am not sure what the implications are

Uday: a thing could be anything, and I hope that we do include constrained devices here.

Johannes: we do, and I wonder what you consider to be the pain points for constrained devices

<zkis> Majority of Things we expect to be implemented on constrained devices, so yes, they are first class citizens.

Uday: Michael and Dave noted the role of gateways for mediating communication between constrained devices

Why can’t we look at constrained API for device to device interaction?

Johannes: it would be good to see a proposal

<zkis> let's have a github issue about this

Johannes: we’ve had implementations on constrained devices at previous Plugfests

If you can provide some tangible info that would be very helpful

<Zakim> dape, you wanted to another issue w.r.t. scripting is that there are also other scripting languages used, like Lua

Daniel: We should not focus on just JavaScript, and we should instead look at what scripting languages are used in the embedded world

Johannes: we could provide bindings to a variety of scripting languages, e.g. JavaScript, Lua, Python, etc.

Zoltan: we can use language neutral API definitions that facilitate such bindings, and we need to provide a test framework for interoperability for the scripting API, and what tests it should be used with

Kaz: I agree with Zoltan and Daniel about the idea for doing a survey of popularity of scripting languages.

<kaz> for example, Franca is used for IVI apps by GENIVI guys

The APIs we define should be compatible with existing practice for these scripting languages

Johannes: I definitely agree with supporting what is out there, however, when we try to support everything our work will never finish

We need to consider what to write in the updated WG charter?

My suggestion is to focus on JavaScript as it is native to the Web, and to also define some C headers as that is applicable to many languages.

Daniel: I like that idea, but we should leave it open for plugging in new language bindings

Zoltan: what about using IDL, not necessarily WebIDL?

Dave: I asked Robin Berjon about this a while back. He pointed out the WebIDL has assumptions that are appropriate for browsers but perhaps not for other contexts

Johannes: let’s create a GitHub issue to collect the points

<jhund> Action on me to create an issue to cover scoping for specification of the APIs

<trackbot> Created ACTION-81 - Me to create an issue to cover scoping for specification of the apis [on Johannes Hund - due 2016-12-05].

Johannes: it is a safe bet to focus on the next Plugfest and keep up the discussion

Johannes asks everyone to review Zoltan’s proposal (see link above)

The next scripting task force call is next week

scribe: end of call …