- 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