See also: IRC log
Joh: Agenda
... 1. Additions & Changes to the Agenda
... 2. Dom presentation (Input about data structures and interactions shifted)
... 3. Input from iotkit-comm
... 4 . Action items
... 5. Examples from Claes
... Any addition/changes to agenda?
Kaj: Update w,r,t. slides via mailing list
Joh: Please start Kajimoto
Kaj: Please open slides
... Slide 2: Original input at F2F meeting in Munich
... Right side: HTTP protocol to WoT server. Wot Server can be
adresses by URI
... WoT server provides REST API
... WoT Server uses TDL document (what/which device)
... status at the f2F
Kaj: Slide 3: Use case home automation
(discovery)
... user uses smartphone ... dicovers available devices
... WoT server is manager. App requests devices. Server
responds with list
... currently Panasonic uses propriatory binary format for data
exchange
Kaj: Slide 4: After discovery App
selects e.g. air conditionar
... next step: which kind of service air conditionar can
provide
... Agent provides device type and additonal information (owner
etc)
... information come from different databases... registration
and/or manufacturer
... "Total Manager" communicates across multiple WoT Servers
and agents
... Slide 5: Users can control device (with previous
information)
... e.g., command cool down to WoT server and WoT Agent
... WoT server interprets "abstract" command and maps it to
"real" command (ECHONETLITE)
... Slide 6: about setup up process
... WoT Server at first does not know devices
... home gateway posts "add new device" to WoT Server
... step3: about including device attributes
... Slide 6: About Notification
<kaz> [p6 of the above slides says "Home Automation (Notification)"]
Kaj: GW pushes to WoT (agent/server) information to smart phone that for example air conditioner has been switched off or so..
Joh: Comments?
... Question: Home Gateway converts between Wot protocol and
Echonet-Lite...where are those servers.. both "in" the
home?
Kaj: WoT server implements GW function.
JoH: Wot server in cloud or in home device?
Kaj: combination
Kaz: suggest differiantate between HW layer and Protocol layer
Joh: Next on the agenda.
Presentation from Dom
... iotkit-comm / Intel is next. anybody here?
... not
... Claes, would you prepared?
Claes: Not ready yet. Could
provide input for next meeting
... tricky part authentication won't be part of it
... will provide input via mail
Joh: Meeting schedule: decided to
have weekly meetings in the beginning... alternating
timezones
... setup doodle... not many people participated
<jhund> http://doodle.com/cw5tdschat6i29w7duhctvzh
Joh: suggest Tuestday to Thursday
due to alternating timezones
... according doodle Thursday looks good
... let's schedule next meeting on Thursday (US timezones)
Joerg: Proposal: shift it always by 8 hours.. will add information in wiki
Joh: Next on agenda: call for
AI
... architectural figures for use case
... are there contributions?
... We have one.. can sart
... Server called serviant (acting as server and client)
... serviant can be connected with other serviants...
... can be connected by browsers etc
... serviant uses protocol mapping
... on top is API..... and Application
... will send figure on mailing list
... any comments
Kovatsch: looks similar to what we have in IETF (combination of server& client)
Joh: Any reference to link to at IETF
Kovatsch: CORE interface draft
uses this approach
... will provide information on IRC
<kaz> MMI Architecture
Kaz: diagram similar to multi modal archcitecture
<mkovatsc> https://tools.ietf.org/html/draft-ietf-core-interfaces-02
<mkovatsc> Only use for the mixed client/server role on devices (for now)
Joh: Did you use a special word for the combined serviant (server: interaction manager and client: modality component)
<mkovatsc> also see https://tools.ietf.org/html/draft-ietf-core-resource-directory-02: devices register in client role and then serve resources as server
Joh: example about REST API
... mapping to protocol ...did not find abstract model.. used
http
... identidied WebIDL for abstract definition of API
... need to define data structure for event
... details can retrieved by following link
... datastracutures across various format should be the
same
... API should use WebIDL
... need to find common denominator accross the many APIs
... server reports errors if any..
... Comments?
Kovatsch: missing concept of
hypermedia type...
... which content type.. how to send data
Joh: There is a task force that should deal with it....
Kovatsch: It is more about the style of the API (e.g, RMI)
Joh: will publish document... Mattias can you annotate what you mean
Kovatsch: sure
DP: should make it available.. so that other have a better change to comment.. (said already)
none
Joh: will send out arch figure
and document via mail
... will also inform you about next meeting
[adjourned]