<inserted> scribenick: kaz
kaz: diagram update, interface template, event handling, registry/discovery procedure
mccool: security a bit
<scribe> scribenick: mlagally
kaz: diagram was updated to include latest applications
<kaz> Kaz's generated branch of preparation.md for the updated diagam
<kaz> pullrequest #390 for the change
(no objections to merge the change)
(pullrequest #390 has been merged)
<yamada_> https://github.com/w3c/wot/blob/master/plugfest/2018-prague/preparation-panasonic.md
yamada-san presents interface template
yamada: I updated protocol and
interfaces table - descriptions about servient interfaces were
added
... Burlingame additions are highlighted purple
koster: long polling interface is for
apps only?
... or for servient as well?
yamada: all apps can use this, not only Panasonic
mccool: only for events?
... example - get next frame of a camera - is this
supported?
koster: observe would work for
that
... long polling is only for observe over http - in the TD
there are two uri's for that: one for read and one for
observe
mccool: use case to give clarity?
koster: there's a uri for reading a
property, another one for observe
... discussion about long polliing / streaming
<inserted> Kawaguchi-san's slides
Kawaguchi-san presents "Event/Property observe proposal"
kawaguchi: shows sequence diagram
mccool: do we support timeouts - what happens if the proxy goes away?
kawaguchi: not yet considered
<McCool> My point was more if the client goes away... the proxy should eventually give up and cancel the connection
<McCool> although there might be a different issue if the proxy goes away and the client has to reconnect, I think that can be handled as an error the client has to explicitly recover from
<McCool> there is also a question of what to do if the server dies
koster: how do you send unsubscribe?
<McCool> I think the way to deal with that is to have the client or proxy periodically "refresh" the observe
kawaguchi: diagram may not be precise
mccool: there will be a tcp
timeout
... client should refresh the observe
... is this handled automatically?
koster: I would use this rather than
websocket proposal
... if you want an immediate response, you can use read
property
Kawaguchi presents TD snippet example - last time we used a different http server for handling observe property
kawaguchi: rel "observe" implies the use of long polling
mccool: should we define a different name for that?
matthias: we should use additional vocabulary - otherwise we cannot distinguish
<kaz> +1 to Matthias
discussion continues: headers - new tags ...
matthias: there could be multiple relation types
koster+mccool: new tag
mccool: we could use "mode"
<McCool> eg. "mode" : "polling"
koster: let's look at others, e.g. ietf to find best term
<McCool> but I agree with Koster we should do a survey
koster: one of the patterns did an upgrade to Websock - is this done during init or each time during a subscription?
kawaguchi: this is another pattern
<presents Event TD snippet>
... event subscription is using long polling
matthias: if there's only one entry
in the form, you can ommit "rel"
... if you have an observable property, the client has direct
access to the state - an event does not grant direct access -
does not immediately expose state
mccool: coap uses this for eventual
consistency
... bumping into a robot example - you cannot figure out what
happened in the past
... observe and events are handled similarly at protocol level
- this may be handled differently here
kawaguchi: <final slide>
matthias: open a separate web socket
connection for each property is one option - if you follow your
approach this appears to be a new protocol
... eg. coap over websock
kawaguchi: +1
... we would have to define this protocol
koster: is not fully described by
uri
... do we need a separate port for each connection?
... this is a http-only problem - extend the vocabulary? new
subprotocol?
mccool: these protocols have same
structure, multiplexing wrapper?
... we may be able to specify this.
matthias: how much effort for simple websocket approach?
kawaguchi: need to discuss within company
koster: different ports?
matthias: yes
mccool+koster+matthias: consider firewalls, use http / https
kaz: how to deal with protocol keyword for long poll? Matthias - will you talk with IETF?
mccool: let's pick a temporary name and do a survey
matthias: let's start with a strawman
mccool: let's just pick a temp name
and start the survey
... we need a name for the plugfest
kawaguchi: conclusion: do we have a temp name
mccool: subprotocol-long-poll
koster: any open logistic issues?
scribenick: kaz
mlagally: if you have any specific requirements, please let me know
scribenick: mlagally
mccool: everyone brings own switch -
Siemens brings Wifi bridge
... does the Wifi prevent multiple connections, limit bandwidth
, ...?
kaz: requirements put into preparation.md?
mccool: update Wiki to point to the md file
koster: will create a network requirements file and put into plugfest planning Wiki
matthias: our switch has 4 ports, everyone should bring their own switch
mccool: we had Wifi problems last times - I prefer wires this time
<kaz> [adjourned]