W3C home > Mailing lists > Public > public-wot-ig@w3.org > November 2016

[scripting] minutes - 28 November 2016

From: Kazuyuki Ashimura <ashimura@w3.org>
Date: Mon, 28 Nov 2016 22:09:23 +0900
Message-ID: <CAJ8iq9UH2NypuF5_dG-feV33VEMbmLgLXrUKjb0e+Ay4CxiWAg@mail.gmail.com>
To: Public Web of Things IG <public-wot-ig@w3.org>
available at:

also as text below.

Thanks for taking these minutes, Dave!



      [1] http://www.w3.org/

                               - DRAFT -

                     WoT IG - Scripting task force

28 Nov 2016


          Dave_Raggett, Kaz_Ashimura, Jim_Lim, Daniel_Peintner,
          Johannes_Hund, Uday_Davluru, Yingying_Chen, Zoltan_Kis,




     * [2]Topics
     * [3]Summary of Action Items
     * [4]Summary of Resolutions

   <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> [5]https://github.com/w3c/wot/pull/282

      [5] 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]



   Johannes: please read and comment

   Many thanks to Zoltan for providing this

   Johannes: I would like to discuss two issues.

   <kaz> [7]Issue 240

      [7] https://github.com/w3c/wot/issues/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> [8]Issue 235

      [8] https://github.com/w3c/wot/issues/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

   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

   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

   Uday: We should include use cases that cover constrained

   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

   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

   <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

   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

   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

   The next scripting task force call is next week

   scribe: end of call …

Summary of Action Items

Summary of Resolutions

   [End of minutes]

    Minutes formatted by David Booth's [9]scribe.perl version
    1.148 ([10]CVS log)
    $Date: 2016/11/28 13:08:23 $

      [9] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [10] http://dev.w3.org/cvsweb/2002/scribe/
Received on Monday, 28 November 2016 13:10:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:27:08 UTC