Web of Things TF-AP Meeting

<scribe> scribe: TK

<scribe> scribeNick: taki

Johannes: Topics are Plugfest face-to-face. And, Interaction model of discovery.

Discovery API patterns (Louay)

<Louay> https://github.com/louaybassbouss/wot/blob/di-flows-bindings/TF-DI/DiscoveryFlowsAndBindings.md

LB: Discusses discovery patterns and flows.
... Consumer, Client looks for things. Server offers things.
... Registry. Manages thing description.
... Generator is a pattern. How to generate description from templates.
... Each pattern has three paragraphs.
... First flow, we already had at plugfest. Registry, Thing Provider and Consumer.
... First step, query. Last step is to get Thing description. Only focuses on discovery.
... Consumer and Provider use the same registry.
... Sparcle query, for example.
... Second pattern. Registry advertises URIs.
... Consumer doesn't need to know URI of registry.
... Third pattern. There is no registry.
... Each provider advertises URIs.
... Suitable for home. Offline use.
... SSDP and bluetooth low energy can be used.
... Consumer and provider need to be in the same network.
... Flow 4. Similar to 3. Suitable for mechanism without filitering.
... Last pattern. Provider is not compatible with WoT.
... Consumer can discover this.
... BLE, not compatible with WoT. But you can get meta-deta of this device.
... Consumer, given this meta-data, can send this data to Generator.
... Consumer will get a Thing description that has all information that contains BLE binding.
... Does't have to repeat this again.
... Second section is bindings.
... SSDP, mDNS etc.
... We can use it in Plugfest.
... We need specific type. W3C Things. Provider needs to know the type.
...
... In addition to location, I added new header, URI to the Thing description.
... Thing disappear, byebye message can be sent.
... Optional parameters for sending query. We can discover things that are "light".
... Sparkle query, or others can be used.
... New parameter, Link to description. Query is used or not is another option.
... This is just one idea to get Description.
... We will do the same for other subsections.

MK: This is one way to advertise.
... Server pattern should also be considered.

LB: 5 patters are not the whole picture.
... Your point is similar to pattern 2, or 3.
... This is just SSDP binding.
... I will add other bindings. Will add things like resource directory.

JH: How to abstract those flows, so that we can design APIs. Filter objects, URI of thing provider so on. Any inputs?
... What if I have server that serve multiple things possible?

LB: You always send input, and get result.
... result description.
... Depending on technology, you need address of registry in flow 1.
... We discussed last time, each discovery technology uses different filters.
... But we can use the same filter.

JH: Servient hosting multiple things?

LB: All the flows, servers serve multiple things. In most cases, multiple things are used.
... Servers can send multiple description.

CN: IETF Core. Binding should be defined. Resource directory.

LB: BLE, Zigbee, for example. If we want to use existing discovery protocols, we need bindings.

DP: We would need specific binding. SSDP. How much work to enable SSDP for plugfest?

LB: Not very complex. Depends on platform. Modules for SSDP available.
... Advertising things, discover things, 10 lines of code.

<jhund> title: Web of Things TF AP call

LB: We have experiences and modules. Node-JS makes it very simple.
... We need to agree on Messages.
... We use property. TD.WOT.W3C.ORG. This new header.
... Implementation was not complex with Node-JS on Android.

<Louay> https://github.com/fraunhoferfokus/peer-ssdp

JH: Your presentation is enough for implementation?

LB: For SSDP, I think yes.
... If you see the binding. You see query header. We should agree on language, such as sparkle.

JH: You need to register things?

LB: We can use the same registry we used in plugfest. Client discovers this end point.

JH: Registry needs to be enhanced.

LB: I will do the same for mDNS.
... We should use the same technology, such as both side use SSDP.

JH: Browser can use it?

LB: Browser can't use it. You can use Cordova for that.

JH: Registry is a client in that case.
... Can we come up with one or two ways to implement for plugfest?

LB: SSDP, mDNS, Eddystone.
... Android and Cordova.
... We can still test Android against Node-JS.
... We can add columns. Things are discoverable, which technology. Client supports discovery, which technology.

DP: We already have column for discovery. Technology part is missing.
... Current registry needs to support for SSDP, for example.

LB: Registry runs on NodeJS?

DP: It is Java.

LB: Advertiser and registry can run on the same machine.
... We can also support query.

Status F2F / Plugfest

JH: Looking at meeting page.
... Seems there are not big changes.
... We have F2F page. Hotel, registration fee.
... Preparation on Sunday.
... Monday is open day and plugfest.
... Tuesday and Wednesday are reguar meeting.
... Sebastian invites Bosch. I am approaching MIT.
... We have presentation from Soumya.
... Sunday preparation starts at 11am.
... We would like to know people come in the meeting or not.
... Please describe what you bring for plugfest.
... so that we can come up with scenarios.
... If anyone already knows implementation, please describe.
... If you know any other presenter at Open Day, please let us know.
... Thank you for participating. Louay, thank you for presenting today.
... I hope to see you in Canada.