13:01:04 RRSAgent has joined #wot-ap 13:01:04 logging to http://www.w3.org/2015/10/07-wot-ap-irc 13:01:52 RRSAgent, make logs public 13:02:09 meeting: APIs and Protocols Task Force 13:02:15 chair: Johannes 13:02:16 Louay has joined #wot-ap 13:02:28 jhund has joined #wot-ap 13:02:31 rrsagent, set logs public 13:02:41 joerg has joined #wot-ap 13:03:41 Present: Dave_Raggett, Kaz_Ashimura, Louay_Bassbouss, Tatuki_Kamiya, Yingying_Chen, Francois_Daoust, Daniel_Peintner, Johannes_Hund 13:04:23 s/Tatsuki/Takuki/ 13:04:49 agenda: https://lists.w3.org/Archives/Public/public-wot-ig/2015Oct/0007.html 13:05:02 Present+ Claes_Nilsson 13:05:22 Present+ Joerg_Heuer 13:05:31 Present+ Kazuaki_Nimura 13:06:04 Present+ Ari_Keranen 13:06:26 Present+ Arne_Broering 13:06:48 arne has joined #wot-ap 13:06:56 taki has joined #wot-ap 13:07:14 scribe: tidoust 13:07:54 Johannes: [going through agenda] 13:08:33 michael has joined #wot-ap 13:08:45 Claes has joined #wot-ap 13:08:58 Present+ Arne_Broering 13:09:36 Johannes: I note Claes request by mail on documents under development. Other additions? 13:09:43 ... [none heard] 13:09:54 Topic: Plugfest preparation & pre-hackathon on TPAC 13:10:00 -> https://www.w3.org/WoT/IG/wiki/F2F_meeting_29-30_October_2015,_Sapporo,_Japan#Plugfest Plugfest wiki 13:10:00 Present+ Claes_Nilsson 13:10:13 Present+ Darko_Anicic 13:10:51 Present+ Michael_Koster 13:10:57 Johannes: I think that we have the requirements for the demo, is that correct? 13:11:29 Kaz: Basically, the setting should be ok. 13:11:45 ... The demo lists the demonstrations that will be made on the first floor. 13:12:11 Johannes: We could do a hackathon to prepare the plugfest. Some exchanges about rooms. 13:12:31 Kaz: The room next to the main demo hall will be available. That is a room for storage and to keep devices. 13:12:52 ... The meeting planning team suggested to use that room during the day and in the evening. 13:13:01 Darko_Anicic has joined #wot-ap 13:13:16 ... Maybe we can start the preparation at around 3PM. 13:13:34 ... The network will not be available on Sunday though. 13:13:44 ... Same thing for the AC supply. 13:14:00 ... Of course we could bring our devices to the room, but Sunday will not be a good time. 13:14:34 Daniel: Last time we discussed, there was the question of Internet connectivity. 13:14:44 Kaz: For the plugfest within the meeting room? 13:14:47 Daniel: Yes. 13:15:07 Kaz: We could use wired connections and routers to create wifi networks if needed. 13:15:25 ... If we can clarify needs, we can talk to the systems team. 13:15:36 Daniel: And we need to decide who is going to carry around a router. 13:15:58 Kaz: Another question is whether we need Internet connection for the external network. 13:16:53 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. 13:17:17 Kaz: Jonathan filled out that table, need to check with him. 13:17:39 Daniel: Also, if there are too many devices around for discovery, that may be a problem. 13:17:52 Kaz: Right, small local network should solve that. 13:18:39 Johannes: Takeaway is that we could use that storage room with no time bounding. We need to decide whether it's Tuesday or Wednesday. 13:19:12 ... Which would be better, Tuesday or Wednesday? 13:19:30 Kazuaki: I can do both. 13:19:42 Louay: Also available on both days. 13:20:10 Johannes: Others are not on the call. For Siemens, both days are possible as well. 13:20:30 Kaz: in that case, I suggest to try Tuesday first. If that fails, we have Wednesday as a backup :) 13:20:39 Johannes: Right. 13:20:55 ... Any other issue on the topic? 13:21:24 Dave: The request for demos for monday evening. Is anyone willing to provide a demo for the developer event? 13:21:42 ... See mail I sent earlier on. Just a reminder here. 13:22:29 Topic: Technology landscape 13:23:48 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. 13:24:19 ... We need some more depth for the technology landscape. 13:25:01 ... We had some discussions on CoAP for instance. If we could complete the Wiki, that would give us more food to make recommendations. 13:25:02 i|We have|-> https://www.w3.org/WoT/IG/wiki/APIs_and_Protocols_TF#Technology_Landscape Technology Landscape wiki| 13:25:08 rrsagent, make log public 13:25:12 rrsagent, draft minutes 13:25:12 I have made the request to generate http://www.w3.org/2015/10/07-wot-ap-minutes.html kaz 13:25:27 Johannes: Do we have people who can contribute more to this? 13:25:53 scribenick: kaz 13:26:09 johannes: coap section 13:26:15 ... Dave and Claes? 13:26:19 scribenick: tidoust 13:26:32 Claes: Yes, I can write something down 13:26:44 ... Do you want a separate page for that? 13:27:11 Johannes: No necessarily, sub-bullets would be fine. 13:27:50 ... 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. 13:28:09 ... That would create a list of questions to answer for all these protocols. 13:28:24 ... We already discussed them for CoAP, but they probably apply for WebRTC, MQTT, etc. 13:28:34 Claes: OK, I'll see what I can do. 13:29:16 Johannes: Same thing for OneM2M, it would be good to list what protocols they are using. 13:29:19 Soumya has joined #wot-ap 13:29:50 Michael: I would be happy to add some stuff on IPSO and on OneM2M as well. 13:30:00 Johannes: That would be great, yes! 13:30:53 ... Criteria applied to all of these would be quite good. Volunteers welcome! 13:31:21 ... Regarding the tech landscape, I think it would be good to detail the different stacks and protocols. 13:31:55 Dave: Do we have an entry for AllJoyn? 13:32:19 Johannes: Not yet. Do we know someone who is involved in that effort? 13:32:43 Dave: No, but Qualcomm is involved in that organization, so we could get in touch with their AC Rep. 13:33:04 ACTION: Dave to ask Qualcomm about contributions to Tech landscape about AllJoyn 13:33:05 Created ACTION-11 - Ask qualcomm about contributions to tech landscape about alljoyn [on Dave Raggett - due 2015-10-14]. 13:33:37 Michael: They have also something called [missed], which seems interesting to us. 13:34:18 Topic: Scripting API for WoT model 13:34:57 Johannes: I think that Louay has a proposal here. 13:35:16 Louay: [presenting slides on WebEx] 13:35:42 ... Same presentation as I presented two weeks ago in the Discovery call. 13:35:54 ... Idea of an API for the browser to discover and access things 13:36:02 s/[missed]/data driven API/ 13:36:19 ... Some of the concepts are taken from my involvement in the Presentation API. 13:36:30 ... Working on a plug-in for Cordova 13:37:05 ... 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. 13:37:28 ... Second point is to abstract from the underlying protocol. 13:37:42 ... The API could be implemented on top of different protocols. 13:38:13 ... Mainly useful for things that are not registered with a particular server, such as things using Bluetooth Low-Energy 13:39:47 ... [Louay explains the Presentation API, scribe suggests to look at minutes of Discovery call where this part was minuted in more details] 13:40:09 -> http://www.w3.org/2015/09/24-wot-di-minutes.html#item01 Minutes of Louay's Thing API presentation in Discovery call 13:41:09 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. 13:41:34 ... Chrome, Firefox implementing the Presentation API right now. 13:42:01 ... The idea with the Thing API is to use the same concept, because there are common features between the two cases. 13:42:36 ... 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. 13:43:30 ... A "ThingRequest" constructor would take a filter object that describes all things that are of interest for the app. 13:44:16 ... 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. 13:45:27 ... 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. 13:46:24 ... Then the Web page gets a Thing instance, on which it can read/write properties or call actions. 13:46:42 ... The web application will be notified when things are no longer available. 13:47:17 ... We started to implement this as a Cordova plugin, here only on top of HomeKit, so only available on iOS. 13:47:44 ... This is one showcase we want to present at TPAC. 13:48:36 ... 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. 13:49:04 ... So it's not only an application but also a Service. 13:49:18 ... This is the reason why we need to run the app in the foreground on iOS. 13:49:55 ... I received feedback from Francois and Dave. 13:50:19 ... Dave's comments are centered on JSON-LD. I don't think they apply to the API itself. 13:51:23 ... 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. 13:51:56 ... Second comment was about how browsers may handle a large number of things that they discover. 13:52:47 ... 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. 13:53:40 ... 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. 13:54:59 Louay: 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. 13:55:34 ... In the Generic Sensors API, there is no discovery. You can directly check whether a sensor is available. 13:55:46 ... Questions? Comments? 13:56:38 Johannes: Can we view the API in two parts, the native selection box and the Thing API itself? 13:56:41 Louay: Yes. 13:57:09 Johannes: Then there is the ability to expose the discovered Thing as WoT Servient. Is that part of the API? 13:58:07 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. 13:58:45 ... All the information you need will be in the Thing description file 13:59:11 Johannes: The reason for my question is that this would enable Thing-to-Thing communication in a very unified way. 13:59:45 ... This would provide a way to discover things, wrap them for exposure, and expose them to other things. 14:00:38 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. 14:00:59 ... We need other parts for registering things. Not part of the browser API, I think. 14:02:01 Johannes: OK, but you form a proxy for the thing. 14:02:19 ... I wonder why the split between the two parts. 14:02:46 ... Risk of fragmentation depending on protocols used. 14:03:37 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. 14:03:57 q+ on API for accessing things 14:04:20 q+ to ask about API for accessing things 14:04:44 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. 14:05:34 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. 14:06:51 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. 14:07:40 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? 14:08:09 Dave: Well, you may not be the only one accessing the thing in any case. There may be something behind the scene. 14:08:28 Louay: You propose something such as "thing.colorTemperature = 42"? 14:08:38 Dave: Right, for devs, I think it makes sense. 14:09:10 ... One question is to what level we need to standardize this API. We need to define a data model, sure. What else? Open question. 14:09:49 Louay: We could use the event on Monday to get feedback from developers for instance. 14:10:12 Dave: As an IG, we should explore different options, I think. 14:11:23 ... 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. 14:11:45 Johannes: Would it be possible to upload the script examples in your slides to the GitHub pages? 14:11:51 Louay: Yes, I will do it. 14:12:35 scribenick: kaz 14:12:50 tidoust: tx for mentioning all my comments 14:13:09 ... please note Generic Sensor API work handles similar topics 14:13:21 ... could converge common APIs 14:13:42 ... upcoming draft will be published soon 14:13:55 ... TPAC would be a good opportunity to start discussion 14:14:29 louay: Generic Sensor API focuses on reading data 14:14:47 ... while WoT APIs handle accessing actuators 14:15:04 tidoust: right 14:15:16 q+ 14:15:29 scribenick: tidoust 14:16:00 Kaz: Unfortunately, DAP will not have a meeting at TPAC, but Tobie will be there. 14:16:34 ... We can probably have some joint discussion on Tuesday or Wednesday with him and other people from DAP. 14:17:15 -> https://www.w3.org/wiki/TPAC/2015/ad-hoc-meetings#Generic_Sensor_API ad-hoc meeting proposal (Tuesday) 14:17:44 -> https://www.w3.org/wiki/TPAC/2015/SessionIdeas#Generic_Sensor_API Breakout proposal (Wednesday) 14:17:50 Joerg: Maybe we should have a short list of ad-hoc meetings to the IG agenda. Already a couple planned. 14:18:02 +1 14:19:42 Johannes: skipping tooling for today in the interest of time. 14:20:04 Topic: On-going deliverables of the Task Force 14:20:21 -> https://lists.w3.org/Archives/Public/public-wot-ig/2015Oct/0011.html Claes's message 14:20:30 Claes: I had a look at the documents referenced by the Wiki and I wondered which of them are still being pursued. 14:20:58 ... For instance, the Architecture Model, is that still relevant? 14:21:28 Johannes: I would like to open that question for the group. 14:21:39 ... [no comment heard] 14:22:12 ... During the F2F meeting in Sunnyvale, we made an attempt to bring different views for the Web of Things model and architecture together. 14:22:27 ... However, we did not reach consensus to draw this into one picture. 14:22:38 ... It's not very clear to me how we can move forward. 14:23:31 Michael: I would suggest that we list documents that have clear group consensus and that we maintain. 14:23:46 ... Not doable overnight, but that's a question I got as well 14:24:05 Dave: Right, by charter, we also need to publish reports that represent consensus of the group. 14:24:22 ... We need to make it clear what parts are work in progress 14:24:46 ... I think it's a question for the group as a whole. 14:25:09 ... Something that the Chair and TF leads could work on for preparation for the F2F in Sapporo? 14:26:24 Joerg: The most pragmatic is to discuss this by email. Whether the Wiki is fine, where we put parts which have consensus, etc. 14:26:34 Claes: That sounds good. 14:29:53 Dave: The different task forces are working in the right direction, e.g. security 14:30:18 Johannes: Where do we have the reference? How can we ensure that we have a good list of documents? 14:30:36 Dave: Maybe start from the group's home page with a list of documents on the right. 14:30:44 ... And same thing on the IG wiki. 14:31:34 Johannes: Problem is to assess the maturity of documents. 14:31:57 Claes: Wouldn't it be good if task leaders take a stab at it? 14:32:01 scribenick: kaz 14:32:28 johannes: I'd get an action item for that 14:32:41 ... to describe the status of the documents 14:32:55 claes: which document for us to contribute 14:33:32 johannes: could list the existing documents 14:33:45 q+ 14:34:04 ... that would be feasible 14:35:10 kaz: we can add links to the existing documents to the "Work in progress" section 14:35:28 ... and the moderators can add brief description to each list item 14:35:39 -> https://www.w3.org/WoT/IG/wiki/APIs_and_Protocols_TF#Work_in_progress work in progress section 14:35:43 johannes: ok 14:35:46 claes: ok 14:35:54 johannes: other TF managers should also do that 14:36:15 ... and make the decision on which to be continued during TPAC 14:36:34 ... have we addressed all your points, Claes? 14:36:36 claes: yes 14:36:43 johannes: tx 14:36:58 ... we're getting out of time 14:37:03 ... any other business? 14:37:11 (nothing :) 14:37:34 [ adjourned ] 14:37:38 rrsagent, draft minutes 14:37:38 I have made the request to generate http://www.w3.org/2015/10/07-wot-ap-minutes.html kaz 16:22:05 dsr has joined #wot-ap