Meeting minutes
Agenda
Lagally: (goes through the agenda)
Minutes
Lagally: (goes through the minutes)
approved
Scalable Event Model
wot-thing-description issue 1323 - Missing event/notification affordance or operation
Lagally: (shows the diagram within the issue)
Lagally: a servient having two different roles
… Consuming Thing and talking with another Thing
… subscribe operation and unsubscribe operation
… then notify operation
… my idea is TD can describe all of them
… TD has the Event affordance
Thing Description - 5.3.1.5 EventAffordance
Lagally: (explains the vocabulary term there)
… if we want to describe a Consumer
… who receives the events
… some backward communication within the Consumer Servient
McCool: we have notification from the Thing
… the Consumer responds
Lagally: yes
McCool: not clear which side touches what
… the diagram could be improved
… you want to describe the metadata on the interaction here by TD
… for example, the data payload and the data schema
… good to indicate where the related various pieces are
Lagally: there was a proposal by Ege below within the issue
McCool: Sebastian mentioned the example was odd
Daniel: don't want to argue the diagram itself
… but what you were saying was
… not just exposed side
… so far don't understand it
… I'm confused
… seems to be trying to describe both the sides
… we need to clarify what we want
Lagally: simple example here
… is an intermediary
Daniel: we need to understand what is needed
Lagally: you may communicate additional data
… my generic thinking is
… if we can make this a generic model, the discussion would be easier
Sebastian: looking at this diagram and the TD spec
… adding statusresponse itself is fine
… but everything you want to do can be done by TD already
… so don't really understand what is needed here
… what is the actual difference between the two example TD, for example?
two TDs withing Lagally's comment
(FireAlarmButton and FireAlarmListner)
Sebastian: why the second TD (FireAlarmListener) is needed?
… how/who consumes it?
Lagally: (shoes a part of the first TD, FireAlarmButton)
… getting understand your point
"type": "object", "properties": { ... listener: uri, ... } }
Sebastian: you have to provide information using a "Form"
… but the content of TD should be the same with the data you provided
… expressing what the Thing should do for you
Lagally: data vs dataResponse
Sebastian: you should define the expected Action here
… the question is what would be the value of the information here?
Sebastian: you have to set up a new Thing for the Consumer side
… if the Consumer thinks the original Thing can't fit its usage, the Consumer needs another Thing
… you can only communicate with the Thing already defined on the Thing side
… so I don't understand what is needed here...
Lagally: we should see what can be done/implemented during Plugfests
… not suggesting we should standardize this approach right away
… we can have a workaround, but having this kind of additional mechanism would make things easier
… I can come up with some implementation for the Plugfest
Sebastian: the question is that we need to freeze the normative features for TD 1.1
… I believe what you want to do can be done by the current TD 1.1
… we need to finalize the spec shortly
… and we've already started the wide reviews
Lagally: I know
… please see the PRs here
PR 1329 - Event consumer: Alternative 1 - event operation
Sebastian: that PR is for additional "datarsponse" field
… and I'm OK with the addition itself
… but we don't need Consumer TDs
kaz: TD should concentrate on the generic data model for WoT
… and this kind of detailed event handling mechanism should be done as part of the possible management Thing and the processing model for that
Lagally: if we strike out the "Application" part from the diagram, probably the story would become easier
… we just need the "Consumed Thing" on the Consumer side
… and the "Exposed Thing" on the Thing side
Cristiano: the problem here is
… the diagram is quite generic
… every thing event can be mapped here
… we can describe it successfully using the current TD already
… the diagram shows too tight coupling
… having two TDs working together itself would make sense
… but not sure how to handle them
Lagally: think about the telemetry example
… Thing talking with a cloud service
Cristiano: I've looked at Ege's comment about that point
… we should concentrate on that use case then
… and think about what is really needed
Sebastian: any reference for that?
Lagally: need to search for the resource...
McCool: we should discuss the next steps given the time
… introducing an additional feature
… but are we OK with the gap for the use case?
Lagally: let's assume we have data and dataresponse
McCool: I'm OK with having dataresponse itself
… would suggest we focus on event handling caused by the change
Lagally: ok
kaz: are we OK with accepting PR 1329 then?
McCool: except additional notify
Lagally: I'll work on the change and remove the additional "notify" then
… would that be acceptable?
Sebastian: I'm OK with "dataresponse"
Lagally: will create another PR for that then
proposal: Lagally to create an updated PR for dataresponse without notify
proposal: Lagally to create an updated PR for dataresponse without notify (can be included in the 2nd WD if possible)
RESOLUTION: Lagally to create an updated PR for dataresponse without notify (can be included in the 2nd WD if possible)
PR 702
wot-architecture PR 702 - regenerate assertions
(no objections; merged)
McCool: please create a test directory for that
Lagally: would defer it
Lagally: would like to discuss it next week
[adjourned]