Web of Things Interest Group Teleconference -- 21 Oct 2015

<trackbot> Date: 21 October 2015

<jhund> Webex: https://mit.webex.com/mit/j.php?MTID=ma8aa4594b4fc8a5d7728eb2a586917ce

<scribe> scribenick: dsr

<scribe> meeting: APIs and Protocols Task Force

Preliminaries

Joahannes introduces the meeting.

any other topics for today?

Kaz asks Johannes to discuss the Yokohama T2TRG (IRTF) meeting.

<kaz_> IRTF joint meeting

Johannes: this would follow on from the previous WoT IG/T2TRG meeting in Prague

This meeting will take place in Room 304, InterContinental Yokohama Grand, 1-1 Minatomirai Nishi-Ku

Yokohama, Japan 200-8522

As the IETF groups are already active over the weekend it seems pragmatic to co locate the meeting in Yokohama. We are going to start early on Saturday 2015-10-31 (09:00) and end officially on Sunday 2015-11-01 at 16:00.

Kaz: do we to register and pay for the IETF?

Johannes: no, this IRTF joint meeting is free.

TPAC preparation

<inserted> TPAC agenda

We should plan for the 3 hour break-out and gather suggestions in the wiki.

Johannes: we have an in depth discussion on modelling during the last face to face. This time I would like to spend some time on scripting APIs

Dave supports the idea of a discussion on scripting

Claes: maybe we could discuss bi-directional communication, keep-alive, firewalls and so forth.

Daniel: we should also try to set some milestones for the task force

Johannes: yes this can be part of the goal setting and what kind of outcome we are looking for

Daniel: maybe we should look at what people have been implementing and discuss what would be needed for convergence?

Dave: we should look at messaging over protocols, e.g. web sockets, and MQTT where REST doesn’t really apply.
... we should clarify what the benefits of REST are for the WoT
... let’s not forget MQTT and XMPP, etc. when it comes to messaging.

Johannes: for XMPP you could layer REST on top of it or instead use a native messaging scheme

Ari: in the IETF there is work on pub-sup with CoAP that we should be aware of
... Michael and I are co-authors of the corresponding Internet Draft

Michael: an assessment of REST will feature strongly in the T2TRG meeting

We should discuss how things fit together, rather than is something REST or not

Ari: We could spend time on RESTful design for IoT, based upon my email yesterday, see: https://lists.w3.org/Archives/Public/public-wot-ig/2015Oct/0066.html

Claes would like to hear more on that

Johannes: I will gather ideas from today’s minutes for the TPAC agenda

Johannes asks for input for the status report for the plenary session.

Dave asks if we should note that we’re considering discussion of APIs for low level system interfaces, e.g. GPIO, I2C, SPI, etc.

Johannes: yes I can mention that
... I am looking for volunteers to help to fill out the landscape of what has been done either in companies or other standards organisations.

Dave: I agree, and am reaching out to the Allseen alliance as an example.

Michael: I can help with the OMA and IPSO Alliance. Do we have a table in the wiki we can fill out?

<kaz> tech landscape wiki

Johannes: we need to agree on a set of criteria before we can create the table

<inserted> -> https

<Darko_Anicic> Discovery Solutions IoT Consortia

Michael: if we can add columns that would help

Dave: we could ask for contrbutions of implementation work by companies in the WoT IG, e.g. RWE and their LemonBeat work.

Kaz: the Chirimen work too

<kaz> Mozilla work discussion

Johannes: is anyone familiar with the AIOTI?

Dave: yes for WG3 standardisation
... we should look at research projects, e.g. IoT-A, see http://www.iot-a.eu/public/public-documents
... once we have a preliminary document we can reach out to external industry alliances and SDO’s, e.g. the IIC

<scribe> ACTION: Johannes to prepare an initial table in the wiki for the AP TF [recorded in http://www.w3.org/2015/10/21-wot-ap-minutes.html#action01]

<trackbot> Created ACTION-13 - Prepare an initial table in the wiki for the ap tf [on Johannes Hund - due 2015-10-28].

Resuming discussion on low level APIs and role of browsers

This follows on from the email thread on the list

See: https://lists.w3.org/Archives/Public/public-wot-ig/2015Oct/0035.html

kotakagi: Our API is from browser scripts to hardware capabilities like GPIO etc.

see https://github.com/browserobo/WebGPIO and https://github.com/browserobo/WebI2C

kotakagi: We will provide an explanation during TPAC in the breakout session.

<stakagi> Although a headless browser is also considered, browsers with a screen are many cases.

Johannes: most people think of browsers as huge programs, but for Chirimen is more about headless browser which is much smaller, right?

Does the browser have something like a web server?

[ no answer - audio problems?]

<kaz> [ guess at least the Chirimen board has server capability as well ]

<stakagi> It is a client basically.

<stakagi> CHIRIMEN are a browser and a client basically.

Dave: we should survey how different platforms have address the common low level capabilities

Johannes: we need some way to structure the analysis - what things are done in a common way, and where things vary across platforms

<stakagi> However, since examination of the push function is going, a modern browser may play a role as a server.

Dave: we should gather the set of the low level capabilities, some are very common, some are specific to families of chip sets

Johannes: we could start with a list of run-times and SDKs

<stakagi> https://www.youtube.com/watch?v=KykR4eNVB6w

<stakagi> this is one of chirimen's usecase

Michael: the browser software is essentially a scripting engine and set of APIs. There must be a connection to a server to load the software. Can we come up with a thing description language that fits well with HTML

This relates to HATEOAS ...

Johannes: what is the benefit over say JSON?

Michael: markup provides a DOM

These are just different metadata formats that clients could support

Johannes: browser have access to JSON and JavaScript, but not to CoAP and its link headers

Dave: other groups may be interested in different serialisations of metadata as RDF, e.g. XML & EXI, Turtle and N3, and so forth.

dape: yes if the underlying RDF is the same that would be feasible

Michael: if you stick with the web linking approach, this is applicable to most linked data

JSON-LD allows you to separate the RDF node URIs so that you can use simple name/value pairs

Dave: we will need to ensure that what we do is appealing to regular web developers who tend to have an alergic reaction to the overheads in RDF and XML namespaces

Johannes: we need to collect the ideas we’ve discussed at enter it into the landscape wiki, any volunteers?

Michael offers to help

<kotakagi> Sorry. My audio environment is not good. Please let me explain WebGPIO/I2C at breakout session or WoT IG F2F. And we have a plan to show you CHIRIMEN on Wednesday.

Johannes: any other business

… end of meeting and safe travels …

<stakagi> Bye,

<kotakagi> thanks. bye

- DRAFT -

Web of Things Interest Group Teleconference

21 Oct 2015

Attendees

Contents

Preliminaries

TPAC preparation

Resuming discussion on low level APIs and role of browsers

Summary of Action Items

Scribe.perl diagnostic output