Hi all,
Please find the meeting notes from yesterday’s Sparkplug Spec Project Team Meeting below.
Sparkplug Spec Project Team Meeting - Meeting Notes - 18 May 2021
- Attendees (8)
- Chad Kienle
- Bryce Nakatani
- Dominik Obermaier
- Frederic Desbiens
- Ian Craggs
- Mitchel McPartland
- Nathan Davenport
- Wes Johnson
- Assigned GitHub issues 7, 39 and 83 to Dominik/HiveMQ
- Issue 7: Recreating Flow charts is complete (Lucas @ HiveMQ)
- PR will be posted soon
- ECA needs to be completed by Lucas
- Issue 83: Compile all normative statements into a list at build time
- Issue 39: High Availability
- No progress yet, but Dominik can get to it 2+ weeks out.
- Lucas will help with TCK work after completing issues outlined above.
- Wes to set aside more time to complete spec
- Wes has completed Chap 6 spec updates
- 100+ normative statements in the spec, more coming...
- Revisit: Assertion test execution and whether we bail out immediately or attempt to continue.
- Wes: we should bail immediately as continuing can be problematic and not doing so complicates our test authoring/execution up front
- Long term we should allow for tests to be disabled and continue after a failure if possible.
- How to confirm that the Primary Host App received the appropriate N* and D* messages from an Edge Node?
- A custom P.H. implementation needs to be implemented in Tahu to handle these scenarios/facilitate testing.
- Not easy to verify that P.H. received N* and D* messages if it is not required to “output” something on its end.
- Verification that
- Revisit: Removal of Sparkplug A from spec: First version of SP with payload differences.
- Two options:
- (1) Keep it in the spec and describe it in great detail.
- (2) Acknowledge that Sparkplug A exists, provide historical context, but nothing more. [Project Team prefers this option]
- Wes to follow up with broader community to ensure that usage is minimal and we can go with option 2 above
- Revisit: Persistent Connections: Normative Statements to require cleansession=true?
- Why use QoS 1 messages at all then?
- At least the delivery is more guaranteed if QoS 1 and the client is online.
- The only QoS 1 message in the Sparkplug context is the STATE message.
- QoS 1 / persistent sessions may add substantial value for historical message delivery?
- What about a mixed environment where both SP and non-SP data is being delivered?
- cleansession=false may result in a lot of additional processing for a Primary or Secondary Host Application. This is just one consequence and there are likely more.
- Consensus is to leave cleansession references “as is” for the first release of the spec.
Thanks,
Nathan
|
