- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Thu, 2 Nov 2017 05:20:30 +0900
- To: Public Web of Things IG <public-wot-ig@w3.org>, public-wot-wg@w3.org
available at: https://www.w3.org/2017/11/01-wot-pf-minutes.html also as text below. I found Michael Koster was also kindly taking notes on the #wot IRC channel, so have merged it with my notes on the #wot-pf IRC channel. Thanks, Michael Koster! Kazuyuki --- [1]W3C [1] http://www.w3.org/ - DRAFT - WoT PlugFest 01 Nov 2017 Attendees Present Kaz_Ashimura, Kunihiko_Toumura, Michael_McCool, Tomoaki_Mizushima, Toru_Kawaguchi, Ryuichi_Matsukura, Soumya_Kanti_Datta, Michael_Koster, Takeshi_Sano, Kazuaki_Nimura, Takeshi_Yamada Regrets Chair Kaz Scribe kaz, mjkoster Contents * [2]Topics 1. [3]agenda 2. [4]Servient configuration for PlugFest 3. [5]schedule and organization * [6]Summary of Action Items * [7]Summary of Resolutions __________________________________________________________ agenda kaz: 2 topics ... preparation status and plugfest organization (no objections) Servient configuration for PlugFest [8]Matsukura's updated slides [8] https://lists.w3.org/Archives/Public/public-wot-ig/2017Nov/0001.html kaz: not the md file but additional slides? matsu: slides and also GH update kaz: has just merged the pullrequest matsu: the 1st page is as same as the one last week ... 2nd page is updated one ... please check it ... 3rd page explains a possible scenario ... [Scenario 1] ... Remote application servients connect to each Remote proxy and device servient. ... Each participant setup and check the behavior before the connections. ... [Scenario 2] ... A remote proxy servient can accept request from an application and operate local devices via a local proxy servient. ... The remote proxy has a Thing directory that keeps the TDs corresponding to all devices. ... The application can get the TD from it. ... applications can get TDs from the remote proxy servient kaz: each app can talk with Fujitsu's remote proxy? matsu: yes ... [Scenario 3] ... Local application servients connect to each local proxy and device servient. ... similar to the scenario 1 ... but local apps mccool: there will be proxy on the Internet with my system koster: a possible device servient on the cloud side with my system ... we're making direct connection with the Internet ... sort of like the Osaka case matsu: want to see your setting koster: remote proxy in front of devices ... device servient directly connected with app servients ... also going to have MQTT broker has well matsu: your remote proxy servient expose Thing capability? koster: yes ... how about you, McCool? mccool: kind of complicated ... SSH tunnel scribenick: mjkoster mccool: will tunnel device interactions from local to remote using private protocol scribenick: kaz mccool: the same HTTP available on the both sides through the tunnel kaz: so from which servient or module can you provide device capability to some of the servients in Matsukura's diagram? scribenick: mjkoster mccool: there will be a remote endpoint and local endpoint ... exposing the same interface scribenick: kaz kaz: in that case, maybe the remote server could expose the device capability. right? koster: we see a local endpoint and remote endpoint kaz: is it possible for the remote endpoint (or the local endpoint) to expose the device/application capability? scribenick: mjkoster mccool: there will be a remote endpoint and local endpoint ... exposing the same interface scribenick: kaz mccool: would talk about that during TPAC ... would see simplest proxy ... I'll have application servient ... haven't quite clarified how to handle TDs scribenick: mjkoster mccool: local servient and remote servient use different URLs ... thinking about including both local and remote links in the TD scribenick: kaz mccool: we can discuss it during TPAC matsu: for the PlugFest, we should clarify what kind of interface will be supported mccool: detect motion, etc. ... very simple, e.g., booleans ... brightness control, etc. matsu: would like to discuss the detail during the weekend ... any further questions about those 3 scenarios? kaz: will you update the md file based on those proposals? matsu: slide 2 already included ... 3-5 to be included schedule and organization matsu: schedule for Sat/Sun ... Saturday, Nov. 4 ... 9am: door opens and setup starts ... 10am-2pm: scenario 1/2 ... noon-1pm lunch ... 2-5pm: scenario 2 and scenario 3 ... Sunsay, Nov. 5 ... 9am-noon: app development ... noon-1pm: lunch ... 1-5pm: demos/discussions for TPAC breakout ... [Points of this plugfest] ... Introduce proxy servient to set up a larger scale system ... Proxy servient aggregate applications and devices to easily manage the entire system ... developed 4-layered model ... WoT servients support protocol binding with various device interfaces ... new features ... Thing directory ... Event operation ... connectivity between local and remote ... via NAT traversal ... [Agenda for the breakout on 8th] ... main demonstration and other demonstrations ... main: show the interoperability of 8 implementations ... each: demos from each participant mccool: serial presentation or parallel? ... sequential presentations vs each presentation at booth using poster ... personally like the parallel approach better ... kind of poster session matsu: we need to show the total idea of PlugFest ... main demo on interoperability ... that's very important deliverable of our effort mccool: maybe half and half ... key presentation on WoT in general ... but we don't want to use the whole 2 hours for sequential presentations ... maybe half and half ... or some combination matsu: what do you mean by "half and half"? mccool: depends on the people there ... maybe the first people leave and new people will come ... the poster should be provided for parallel sessions matsu: how to organize the booths? ... first half for the main interoperability demo ... should be shown at the main booth mccool: right ... btw, we're not sure about the size of the room kaz: kind of consensus to have a bigger booth for the interoperability ... and what to be done by the smaller booths? mccool: semantic tagging, etc.? ... we can decide in the PlugFest kaz: you mean the discussion during the weekend? scribenick: mjkoster mccool: we can also illustrate the individual pieces ... we should figure this out on the second PF day matsu: argee mccool: saturday more exploratory, sunday to decide on the breakout and demo ... small teams working on focused demonstrations ... take some time on the first day to summarize scribenick: kaz mccool: we could have 2 kinds of demos ... big pictures ... at the end of Saturday, we should see what to do ... and draft the poster as well ... should have brief discussion on Saturday kaz: right mccool: 30min at the end of Saturday ... and detailed discussion on Sunday ... need to decide what to do on Sunday ... assuming we'll print the posters on Monday kaz: basically in line with Matsukura's proposal ... but not sure if we need to use the whole Sunday afternoon mccool: 30 mins at the end of Saturday kaz: how long should we use on Sunday? mccool: another hour on Sunday ... 1-2pm ... and then focused demo discussion by each team 2-5pm ... including presentation materials ... maybe 30mins for feedback at the end of Sunday ... that is my suggestion ... we could talk about the details about Sunday schedule at the end of Saturday as well kaz: so we should clarify at the end of Saturday how many project teams should be held ... and each project team should work on their project on Sunday matsu: how many of you want to show your own demo? mccool: I do have voice demo, OCF bridging, etc. ... doesn't have interoperability kaz: would be great if we could reuse your voice capability, etc., from the other's servient mccool: maybe not too difficult but... koster: discovery, etc. ... some of the features work with all the others mccool: can we put the schedule on the wiki? kaz: Matukura-san, you need to double check with Taki? matsu: yes ... will check with him ... the last point is... ... [Attention!] ... please share your TDs! ... provide your TDs under [9]https://github.com/w3c/wot/tree/master/plugfest/2017-burling ame/TDs ... note that many guys simply use "my device", etc. ... so please follow some name convention like "company name" + "description" [9] https://github.com/w3c/wot/tree/master/plugfest/2017-burlingame/TDs kaz: meaning "company-device" like "panasonic-airconditioner"? ... or should use capital letter to show the word boundary? matsu: yes kaz: so should be something like "PanasonicCleaner" or "SmartThings-MotionSensor" ... will you update preparation.md? matsu: yes kaz: btw, Matsukura-san need to be get included in the Editors team for the repo mccool: yes ... and the information on schedule and name convention should go into the wiki as well kaz: yes ... at least the schedule part should go there ... tx, Matsukura-san ... please update the md and the wiki koster: one question ... would like to gather information on how people use proxy servients ... making some slides kaz: have you sent the slides out? koster: will do after this call ... e.g., someone said node-wot has some proxy capability ... will send them out kaz: tx! ... any other questions/comments? (none) [adjourned] Summary of Action Items Summary of Resolutions [End of minutes] __________________________________________________________ Minutes formatted by David Booth's [10]scribe.perl version 1.152 ([11]CVS log) $Date: 2017/11/01 20:17:13 $ [10] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm [11] http://dev.w3.org/cvsweb/2002/scribe/
Received on Wednesday, 1 November 2017 20:21:39 UTC