<scribe> scribe: dape
Koster: on Agenda is process
check-list
... talk about servient to servient (with proxy)
... would like to start with review where we are
... what are we developing to help people be prepared
... we have questionnaires
... will turn into W3C forms
... want to collect information what is being implemented
... also, we have regular wiki collecting what people bring
with them
... entry form from previous PlugFests could be re-used
... maybe add additional columns (if necessary)
Daniel: entry form == wiki page
https://www.w3.org/WoT/IG/wiki/F2F_meeting,_4-10_November_2017,_Burlingame,_CA,_USA#Participation
<kaz> https://www.w3.org/WoT/IG/wiki/F2F_meeting,_24-29_March_2018,_Prague,_Czech_Republic?
Daniel: current PlugFest wiki misses entry form
Koster: Yes, need to add
this
... any updates to this kind of wiki needed?
Daniel: Might want to think about splitting PlugFest information
Koster: create new page,
yes
... move the table
<kaz> participation table for Burlingame
<kaz> Prague f2f wiki doesn't have that table
Matthias: fear duplicate information in several places
<kaz> preparation page for Prague
Koster: propose one
location...
... moving to preparation page?
<kaz> +1
Matthias: yes
Koster: PRs for updates should work nicely
Matthias: Powerpoint is also fine..
easy to edit
... need to share information during PlugFest also
Koster: single Powerpoint for all
participants ?
... living document during PlugFest
... Markdown seems easier .... line by line changes
Matthias: Need to take care to avoid duplication of information
Koster: might need to have
slide-deck and Markdown?
... we have wiki, markdown, and ppt
... don't need table of participants on wiki
... will collect entries on markup via PR
... powerpoint for summary
Toru: have preparation.md already
Koster: yes, copy from previous PlugFest
Toru: could make PRs to that MD file
Kaz: Could use markdown table generator
<kaz> tables generator
Koster: Ok, looks good
... get started... please comment if there are suggestions
... next is what we did in Burlingame.... state machines,
diagrams
... implementation guidance and scenarios
... for scenarios we look at discovery, proxy etc
... might we want to start writing test-cases?
... proxy has same system features as a servient
... write to down what we want to test
Kaz: agree
... btw, during the Burlingame PlugFest, there are various applications and devices generated by multiple participants as shown in the following diagram
Various applications and devices connected via proxies in Burlingame PlugFest
Kaz: And most of those applications and devices were connected with Fujitsu's Remote/Local Proxies
... So I've started to think we could use Fujitsu's Remote/Local Proxies as the basic framework and concentrate on the interfaces, (1) the interface between Application Servients and Remote Proxy (green lines on the left side in the below diagram) and (2) another interface between Local Proxy and Device Servients (brown lines on the right side in the below diagram)
Fujitsu's remote proxy and local proxy as a possible framework for various applications and devices
Koster: yes, enables transparent
proxying
... need to provide implementation guidance
... proxy consumes device and expose them
... a) in the same fashion
... b) in a different way (other protocol)
... do we need to think about common TDs?
... is there a thing directory ?
... there are a lot of questions
... Fujitsu has a framework
Kaz: Matsukura-san said can provide them
Toru: what exactly?
Kaz: Local proxy and remote proxy as a packaged framework for PlugFest
Koster: shall we try to organize
review
... what it does
... what can be used
Kaz: yes
... will ask Matsukura-san
Koster: <describes proxy
lifecycle>
... special cases
... 3 directories (which could be connected)
... we start introducing lots of system variables
... what should be our next steps
... suggest to schedule review of Fujitsus framework
... also suggest different guidance documents for the different
proxies cases
Kaz: will talk to Matsukura-san again... about concrete interface description
Koster: Maybe there are some
simple tests we can run
... to ensure basic stuff works
Kaz: yes, this is important
... for CR we need test cases (besides spec itself)
Toru: we should also review what
we did in Burlingame
... what could be the improvements
Kaz: Exactly
Koster: Let's put this on the
agenda for next week
... feedback round during call
... will implement entry form
... get questionnaire made
<kaz> [adjourned]