See also: IRC log
scrbenick: kaz
<scribe> Agenda: https://lists.w3.org/Archives/Member/member-wot-ig/2017Oct/0017.html
<ryuichi> https://github.com/w3c/wot/blob/master/plugfest/2017-burlingame/preparation.md
matthias: updated the figures right
now
... should be reloaded
matsu: created the MD above
... including the materials from my slides
... section 1 introduction
... including background and use case description
... section 2 Servients
... 3 kinds of servients for 4-layered model
... application servient, device servient and proxy servient
(remote/local)
... the idea came from Koster at Binding call
... 2.2 Servients from plugfest participants
... application servient - remote proxy servient - local proxy
servient - device servient
... still mission pieces there
... section 2.3 is missing
... 2.4 is table o Servients and protocols
... very important information
... what kind of protocols are supported between which servient
and which
... e.g., app servient - remote proxy servient
... Fujitsu app servient - (HTTP(S)) - Fujitsu remote
proxy
... Panasonic app servient - (HTTPS+WSS) - Panasonic device
servient
... please add information on your servients
... 3. Application scenarios
... what kind of scenarios for PlugFest?
... 4. High level description of issues
... issues to be solved from people's viewpoints
... for the upcoming PlugFest
... please put your issues here
... next (section 4 again) Deadline and Schedule
... expected schedule
... who provides which servient(s)?
... next week (Oct. 25) specify inter-servient interface
... and then PlugFest itself on Nov 4-5
... that's my document
matthias: if you refresh the page, you can get the updated figures
matthias: possible WebUI app on the local side
matsu: which one?
matthias: "WebUI WoT Client (Siemens)"
on my pc
... and Local Proxy and Device Servients in Munich
... difficult to explain in this 4-layer model
mccool: diagrams in my document as well
matthias: we have different dimension actually
mccool: issue on Thing
Directory
... and local devices
... factory service to create them
matthias: already assumes remote proxy
kaz: maybe we can use another
kind of diagram as well
... e.g., which shows the actual location-based topology
mccool: categories of servients
... 4-layered servients can be explained by the table
... we don't have all the parts in this diagram here
... should make the diagram simpler
matthias: there're kind of stacks
... did some update again
mccool: link to the implemented
codes?
... we should discuss management api as well
kaz: we don't have to stick with
the "layer" here
... we can express the role using the color
... e.g., "WebUI WoT Client (Siemens)" as Matthias did
mccool: yeah
matsu: provide the detailed
information on your part
... and then would like to clarify which servient by whom to be
connected which
... for example, McCool, could you please add your stuff to
this?
mccool: yes, I can
... after Matthias's update
matthias: ok
... going back to the table
... the basic version on PPT was ok
... but multi-column table here is difficult to edit
... maybe easier to use PPT table and put the image of
that?
matsu: ok to edit the ppt and put
the table image here
... Koster, can you add your information?
koster: ok
matsu: and Uday?
uday: will do
matsu: if your name is missing,
please add a row
... can put the updated table on this document
... there are many developers for application servients this
time
... would like to know who will really provide applications
mccool: application servient?
matsu: yes
mccool: Intel as well
matsu: ok
kaz: maybe everybody can send the
information by text to Matsukura-san
... and he can integrate all the information
koster: makes sense
matsu: next, I'd like to clarify
the application scenarios
... please put your ideas to this section "3. Application
scenarios"
koster: question on the
diagram
... how the protocol binding might work
... let's show global scope and local scope
... local scope is accessible in the local network
... mapping of devices and applications
... possibly located on the remote side
matsu: device servient on the cloud side?
koster: yes, on the cloud
side
... shadow devices
... HTTPS-based SmartThings API
matsu: ok
... there are many variations for the upcoming PlugFest
koster: yes, I'll add my pieces
kawa: should we prepare Thing
Description for devices we bring?
... if we share TDs in advance, we can know what to do
beforehand
... useful to application scenario discussion as well
matsu: TD of each device servient should be uploaded on GitHub
kaz: we add TD and actual codes
to the table
... as McCool suggested before
nimura: about TD
... which is the actual version for the Burlingame
PlugFest?
matthias: the target should be the FPWD
of TD
... experimentally could include observable events
... what parts are mandatory and what are not
matsu: everyone wants to know about the differences between different versions
sebastian: good idea
matthias: will add a link to the TD spec and explain the difference
matsu: appreciated
... any other comments?
matthias: was working on the ppt
... please use the latest version from GH
yamada: will do
kawa: question about the
procedure
... pullrequest for ppt?
... don't have write permission maybe
matthias: in that case, you can use pullrequest
matsu: you should use a different
file name
... that would be easier
... any other comments?
(none)
matsu: we should talk about app
scenarios next week
... also posters and facilities
kaz: and inter-servient interface as recorded on the MD?
matsu: yes
... will share a diagram on possible interface sequence
... please share your input as well
... by the next call on Wednesday, 25 Oct.
mccool: regarding poster
... make it professional
... common template would be better
... print it by Monday
... we should have basic content by the PlugFest (on Nov.
4-5)
... can finalize right after PlugFest (on Nov. 4-5)
... last year's template is a reasonable starting point
<mkovatsc> Template: https://github.com/w3c/wot/tree/master/plugfest/2016-lisbon
matthias: Daniel Peintner took care of
the one last year
... template above
mccool: can somebody take an action for this year?
matthias: can do that right after getting the size available
taki: several sizes
available
... will send the information to the list
matthias: please include me directly (in addition to the list)
matsu: how many posters?
sebastian: last time we had one for each building block
matthias: can think about updating building block but quite some work
mccool: architecture, td, etc.
... and each demo
... e.g., Amazon integration by Intel
... So 5 or more
koster: might have one for SmartThings
matsu: we have to assign people to each poster
matthias: yes
matsu: aob?
(none)
[adjourned]