<scribe> scribe: tidoust

Johannes: [going through agenda]
... I note Claes request by mail on documents under development. Other additions?
... [none heard]

Plugfest preparation & pre-hackathon on TPAC

<kaz> Plugfest wiki

Johannes: I think that we have the requirements for the demo, is that correct?

Kaz: Basically, the setting should be ok.
... The demo lists the demonstrations that will be made on the first floor.

Johannes: We could do a hackathon to prepare the plugfest. Some exchanges about rooms.

Kaz: The room next to the main demo hall will be available. That is a room for storage and to keep devices.
... The meeting planning team suggested to use that room during the day and in the evening.
... Maybe we can start the preparation at around 3PM.
... The network will not be available on Sunday though.
... Same thing for the AC supply.
... Of course we could bring our devices to the room, but Sunday will not be a good time.

Daniel: Last time we discussed, there was the question of Internet connectivity.

Kaz: For the plugfest within the meeting room?

Daniel: Yes.

Kaz: We could use wired connections and routers to create wifi networks if needed.
... If we can clarify needs, we can talk to the systems team.

Daniel: And we need to decide who is going to carry around a router.

Kaz: Another question is whether we need Internet connection for the external network.

Johannes: I think we added a column to the table. Soumya does not need connectivity apparently. Let's ask others to fill the column as well.

Kaz: Jonathan filled out that table, need to check with him.

Daniel: Also, if there are too many devices around for discovery, that may be a problem.

Kaz: Right, small local network should solve that.

Johannes: Takeaway is that we could use that storage room with no time bounding. We need to decide whether it's Tuesday or Wednesday.
... Which would be better, Tuesday or Wednesday?

Kazuaki: I can do both.

Louay: Also available on both days.

Johannes: Others are not on the call. For Siemens, both days are possible as well.

Kaz: in that case, I suggest to try Tuesday first. If that fails, we have Wednesday as a backup :)

Johannes: Right.
... Any other issue on the topic?

Dave: The request for demos for monday evening. Is anyone willing to provide a demo for the developer event?
... See mail I sent earlier on. Just a reminder here.

Technology landscape

<inserted> Technology Landscape wiki

Johannes: We have different consortia that are using different technologies. Several protocols from the ones we've identified. If people who contributed to this landscape could also cross-reference the other IoT efforts so that we know which supports which model.
... We need some more depth for the technology landscape.
... We had some discussions on CoAP for instance. If we could complete the Wiki, that would give us more food to make recommendations.
... Do we have people who can contribute more to this?

<kaz> scribenick: kaz

johannes: coap section
... Dave and Claes?

<tidoust> scribenick: tidoust

Claes: Yes, I can write something down
... Do you want a separate page for that?

Johannes: No necessarily, sub-bullets would be fine.
... What would be very good would be to identify criteria that could be applied to all these protocols, such as availability for wide area networks.
... That would create a list of questions to answer for all these protocols.
... We already discussed them for CoAP, but they probably apply for WebRTC, MQTT, etc.

Claes: OK, I'll see what I can do.

Johannes: Same thing for OneM2M, it would be good to list what protocols they are using.

Michael: I would be happy to add some stuff on IPSO and on OneM2M as well.

Johannes: That would be great, yes!
... Criteria applied to all of these would be quite good. Volunteers welcome!
... Regarding the tech landscape, I think it would be good to detail the different stacks and protocols.

Dave: Do we have an entry for AllJoyn?

Johannes: Not yet. Do we know someone who is involved in that effort?

Dave: No, but Qualcomm is involved in that organization, so we could get in touch with their AC Rep.

<scribe> ACTION: Dave to ask Qualcomm about contributions to Tech landscape about AllJoyn [recorded in http://www.w3.org/2015/10/07-wot-ap-minutes.html#action01]

<trackbot> Created ACTION-11 - Ask qualcomm about contributions to tech landscape about alljoyn [on Dave Raggett - due 2015-10-14].

Michael: They have also something called data driven API, which seems interesting to us.

Scripting API for WoT model

Johannes: I think that Louay has a proposal here.

Louay: [presenting slides on WebEx]
... Same presentation as I presented two weeks ago in the Discovery call.
... Idea of an API for the browser to discover and access things
... Some of the concepts are taken from my involvement in the Presentation API.
... Working on a plug-in for Cordova
... The main idea is to define a JavaScript API that allows Web pages to discover and interact with things. Main point is to consider security and privacy by design.
... Second point is to abstract from the underlying protocol.
... The API could be implemented on top of different protocols.
... Mainly useful for things that are not registered with a particular server, such as things using Bluetooth Low-Energy
... [Louay explains the Presentation API, scribe suggests to look at minutes of Discovery call where this part was minuted in more details]

-> http://www.w3.org/2015/09/24-wot-di-minutes.html#item01 Minutes of Louay's Thing API presentation in Discovery call

Louay: Focus of Presentation API is presentation of web content. Audio/video content will be considered afterwards. We have a Cordova plug-in implementing the Presentation API.
... Chrome, Firefox implementing the Presentation API right now.
... The idea with the Thing API is to use the same concept, because there are common features between the two cases.
... The first analogy is linked to the need to discover displays/things. The second analogy is linked to the need to have a communication channel.
... A "ThingRequest" constructor would take a filter object that describes all things that are of interest for the app.
... When the app starts the API, the user agent discovers the things that match the filter. The user selects one thing (possibly more than one) in the list.
... When the web page gets access to a thing, it gets an ID that it can use later on to access the thing again later on. This is useful for usability, as starting otherwise would always display a dialog to select a thing, whereas for things you may want to give access for a longer period of time.
... Then the Web page gets a Thing instance, on which it can read/write properties or call actions.
... The web application will be notified when things are no longer available.
... We started to implement this as a Cordova plugin, here only on top of HomeKit, so only available on iOS.
... This is one showcase we want to present at TPAC.
... The goal is also for the Cordova app to serve as WoT Servient that offers a Websocket server or HTTP server to enable access to the things from other clients.
... So it's not only an application but also a Service.
... This is the reason why we need to run the app in the foreground on iOS.
... I received feedback from Francois and Dave.
... Dave's comments are centered on JSON-LD. I don't think they apply to the API itself.
... Francois wondered whether selection of multiple things would be useful (in the Presentation API, only one display may be selected). I think that's a good idea for things. For the API, instead of one Thing, the application would simply receive an array of Things.
... Second comment was about how browsers may handle a large number of things that they discover.
... I think the API is more applicable to sensors/actuators/things that are not registered on the network, for home automation. That's the main goal of this API.
... Last comment was about the dialog display being shown to the user each time the thing is first accessed. The ID mechanism that I described would give the app the rights to access the thing later on without prompting the user again.
... The Generic Sensors API addresses sensors that are available on the device where the browser is running. Here it's more related to discovery new things and interacting with new things.
... In the Generic Sensors API, there is no discovery. You can directly check whether a sensor is available.
... Questions? Comments?

Johannes: Can we view the API in two parts, the native selection box and the Thing API itself?

Louay: Yes.

Johannes: Then there is the ability to expose the discovered Thing as WoT Servient. Is that part of the API?

Louay: The API addresses the first two parts. To offer the thing to other applications, I will implement another layer. This is really for the plugfest, not part of the API.
... All the information you need will be in the Thing description file

Johannes: The reason for my question is that this would enable Thing-to-Thing communication in a very unified way.
... This would provide a way to discover things, wrap them for exposure, and expose them to other things.

Louay: Yes. You will need specific protocols for discovery and controls, but exposing could use existing standards more easily. The Thing API I propose is not a solution for all the features discussed here.
... We need other parts for registering things. Not part of the browser API, I think.

Johannes: OK, but you form a proxy for the thing.
... I wonder why the split between the two parts.
... Risk of fragmentation depending on protocols used.

Louay: Yes. That is a problem with the Presentation API as well. From an application perspective, you would be able to use the same API but may not end up with the same list of available displays depending on protocols supported by the underlying web browser.

Johannes: If you were to implement a thing such as a lamp. You would have another API to expose a thing. Why not have only one API.

Louay: I agree. This is a basic idea. If you can inject your ideas to extend my proposal, I'd be happy to discuss that next time.

Dave: Just a question about the style for accessing things. To some extent, I think this should be language-independent. Also the question of synchronicity as developers will be more expecting synchronous properties for instance.

Louay: If I set a property and then call an action after setting the property. If I don't wait for the property to be set, how can I be sure the action takes place at the right moment?

Dave: Well, you may not be the only one accessing the thing in any case. There may be something behind the scene.

Louay: You propose something such as "thing.colorTemperature = 42"?

Dave: Right, for devs, I think it makes sense.
... One question is to what level we need to standardize this API. We need to define a data model, sure. What else? Open question.

Louay: We could use the event on Monday to get feedback from developers for instance.

Dave: As an IG, we should explore different options, I think.
... I need we need to get practical implementation experience, so congrats for this work. The plugfest is a nice experiment. We need more of that to point out these issues.

Johannes: Would it be possible to upload the script examples in your slides to the GitHub pages?

Louay: Yes, I will do it.

<kaz> scribenick: kaz

tidoust: tx for mentioning all my comments
... please note Generic Sensor API work handles similar topics
... could converge common APIs
... upcoming draft will be published soon
... TPAC would be a good opportunity to start discussion

louay: Generic Sensor API focuses on reading data
... while WoT APIs handle accessing actuators

tidoust: right

<tidoust> scribenick: tidoust

Kaz: Unfortunately, DAP will not have a meeting at TPAC, but Tobie will be there.
... We can probably have some joint discussion on Tuesday or Wednesday with him and other people from DAP.

<kaz> ad-hoc meeting proposal (Tuesday)

<kaz> Breakout proposal (Wednesday)

Joerg: Maybe we should have a short list of ad-hoc meetings to the IG agenda. Already a couple planned.

<kaz> +1

Johannes: skipping tooling for today in the interest of time.

On-going deliverables of the Task Force

<kaz> Claes's message

Claes: I had a look at the documents referenced by the Wiki and I wondered which of them are still being pursued.
... For instance, the Architecture Model, is that still relevant?

Johannes: I would like to open that question for the group.
... [no comment heard]
... During the F2F meeting in Sunnyvale, we made an attempt to bring different views for the Web of Things model and architecture together.
... However, we did not reach consensus to draw this into one picture.
... It's not very clear to me how we can move forward.

Michael: I would suggest that we list documents that have clear group consensus and that we maintain.
... Not doable overnight, but that's a question I got as well

Dave: Right, by charter, we also need to publish reports that represent consensus of the group.
... We need to make it clear what parts are work in progress
... I think it's a question for the group as a whole.
... Something that the Chair and TF leads could work on for preparation for the F2F in Sapporo?

Joerg: The most pragmatic is to discuss this by email. Whether the Wiki is fine, where we put parts which have consensus, etc.

Claes: That sounds good.

Dave: The different task forces are working in the right direction, e.g. security

Johannes: Where do we have the reference? How can we ensure that we have a good list of documents?

Dave: Maybe start from the group's home page with a list of documents on the right.
... And same thing on the IG wiki.

Johannes: Problem is to assess the maturity of documents.

Claes: Wouldn't it be good if task leaders take a stab at it?

<kaz> scribenick: kaz

johannes: I'd get an action item for that
... to describe the status of the documents

claes: which document for us to contribute

johannes: could list the existing documents
... that would be feasible

kaz: we can add links to the existing documents to the "Work in progress" section
... and the moderators can add brief description to each list item

-> https://www.w3.org/WoT/IG/wiki/APIs_and_Protocols_TF#Work_in_progress work in progress section

johannes: ok

claes: ok

johannes: other TF managers should also do that
... and make the decision on which to be continued during TPAC
... have we addressed all your points, Claes?

claes: yes

johannes: tx
... we're getting out of time
... any other business?

(nothing :)

[ adjourned ]