Meeting minutes
Agenda
McCool: we should talk about the Explainer for Profile
Lagally: (generating an Issue for that purpose)
Lagally: review agenda; testfest, event models, PR
<kaz> agenda for today
minutes
<kaz> Mar-9
Lagally: was two weeks ago, March 9
… no call last week due to plugfest
… discussed event model, 4 alternatives, proposals
<benfrancis> https://
<benfrancis> Follow-up comment: https://
Ben: after call, based on discussion in call, gave followup
<mlagally> https://
Lagally: please update the PDF link in the draft minutes to the above link
Lagally: propose approving after link fix...
… just noticed though we have PDF link twice, but we didn't look at it, so should be fixed in both places
Kaz: URL fixed
Lagally: ready to publish?
… no objections, approved
test fest
<mlagally> PR 181 - WIP: Implementation Report
McCool: so there were a number of fixes for assertion markup
McCool: we need to find a good point to merge them, I will wait
Ben: I also made some changes recently to the ids
McCool: also plan to rename things, update the assertion list, etc
Lagally: would also like to report about what we did in testfest
… talked in testfest about profile validation, testing, etc.
… started working on a JSON schema extension for profile testing
… based on the current profile spec
… just to better understand the process, a starting point
… have a tool right now, but the output is very verbose, includes copy of input TDs
McCool: whether or not the actual things you are testing make it into the final spec, working on the testing process is useful
Lagally: ideally we can re-use the existing TD schema, then add additional constraints
McCool: will this JSON Schema be an appendix?
Lagally: yes, we have a section for it
McCool: would suggest a validation section similar to that in the TD, defining "levels" of validation, etc.
<kaz> Issue 187 - Create validation section
Lagally: Issue #187
… Create validation section...
Lagally: there are also a number of profile test cases now, from Oracle and Ben; still working on event implementations
Ben: was trying to do some testing, curl was working, but not postman
… query action did not work for me, however; status not working...
Lagally: let's discuss offline, and work on implementations
Ben: on my side, profile implementation, have report on github
event model
<benfrancis> WebThings compliance report https://
Lagally: prepared a slide deck
… PR #185
<kaz> PR 185 - Slides for event model discussions (just merged)
Lagally: some baselines that we seem to agree on
… general principles
… may be hard to *require* that a device is BOTH a client and server
… should ideally only have a single protocol binding for each op
… so avoid having mixed protocols in a single profile
Ben: and specifically within a single protocol, i.e. for events
McCool: which means if we don't require both client and server, webhooks won't fly
Ben: ml will get to that...
… an individual profile may not require BOTH client or server, but it needs at least one
Lagally: does single binding per op also mean a single form per interaction
Ben: yes, some nuance to that, but fundamentally yes
Lagally: was some concern from Siemens about that, will have to follow up
… so right now, it looks like we agree on most things except events (and observe)
… so we can call that the baseline HTTP protocol
Lagally: currently in the spec we have SSE for events, but not for observable
… but is a PR for observables
… in similar way we could have a websocket binding for notifications, as a separate standalone thing
… so we could do a baseline HTTP, then add extensions for different event mechanisms
Lagally: we would then put event bindings in extensions
… have dedicated sections
McCool: would then have a baseline http profile, then an event profile you would add?
Ben: not convinced this is a good idea, will cause fragmentation
… we already have an SSE binding, the only use case is when the device is a client; a different deployment scenario
… giving up on events in the core for that one use case seems extreme
… my suggest is to have two profiles
… similar to this, will share common baseline
Lagally: won't have no interop in baseline, for devices without events
… and SSE just is not scalable
McCool: one profile or a profile plus an extension are technically similar
… what we want for interop is to clarify the use cases for each profile
Ben: have servient and client-server profiles
… if we have baseline, plus extension
Lagally: if stick to the baseline itself, then interop is acheived
… so three profiles, really: baseline, servient, and client-server
… many scenarios are possible without events
Ben: do you have an example implementation of the use case you are talking about? It would be very useful to see what bits are the same and which are different?
… we have implementations of the others, but not webhooks...
Lagally: agree, that would be useful, working on it
<Zakim> kaz, you wanted to remind you all that we need to switch to the main call
McCool: some IoT devices, I know of do use webhooks, e.g. Shelly, but profiles are for greenfield, so...
<kaz> [adjourned]