See also: IRC log
<scribe> scribe: TK
<scribe> scribeNick: taki
Johannes: Topics are Plugfest face-to-face. And, Interaction model of discovery.
<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.
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.