kaz: 2 topics
... preparation status and plugfest organization
(no objections)
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
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
https://github.com/w3c/wot/tree/master/plugfest/2017-burlingame/TDs
... note that many guys simply use "my device", etc.
... so please follow some name convention like "company name" +
"description"
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]