Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[sparkplug-dev] Sparkplug Spec Project Team Meeting - Meeting Notes - 09 March 2021

Hi all,

 

Please find the meeting notes from yesterday’s Sparkplug Spec Project Team Meeting below.

 

Sparkplug Spec Project Team Meeting - Meeting Notes - 09 March 2021

  • Attendees (7)
    • Chad Kienle
    • Frederic Desbiens
    • Ian Craggs
    • Ilya Binshtok
    • Nathan Davenport
    • Travis Cox
    • Wes Johnson
  • Progress Report
    • Chapter 1 – 5 Clean-up and normative statements added
    • Count of tests that need to be created is getting larger via normative statements (~15 tests)
    • Chapter 8 (Clustering/HA) – may need to collaborate with Dominik @ HiveMQ
      • Cirrus Link tends to discourage the use of Clustering WRT in-order delivery as it is not guaranteed
      • Ian to discuss w/ caveats with Dominik
      • MQTT Engine has code to work around out-of-order messages. Kafka can also be used to reorder / ensure order...
      • This content could go outside of the core doc in a supplemental doc (e.g., implementation guide)?
    • Misc Open Issues
      • QoS
        • Edgenode WILL messages not called out to be QoS1
        • Why not QoS2?
        • Subscription QoS also not addressed within the spec
      • bdSeq number handling is not super clear and needs to be better described
      • Session state WRT to Birth/Death messages is not clear to all
      • MQTT v5 Support (Issue #75):
        • Ensure State messages, retained and QoS flags
        • MQTT Distributor doesn’t support v5 (HiveMQ broker can be used here for validation)
        • Someone with Cirrus Link can take this task and do a quick sanity test (Nathan @ Cirrus Link will pick this up)
          • Flag in Paho to specify 5.0?
      • TCK tests driven via spec annotations... then how do we run specific TCK tests for a specific profile against an implementation?
        • Portion of TCK gets executed (via profile: edge, host, primaryhost)...
        • Client would then perform operations against it as defined by some test script/scenario annotation that enforces order
        • No previous work that we can follow, so therefore no hard constraints on implementation
        • Assertion annotations ordered? Maybe they should be?
          • We should minimize constraints on potential compatible implementations... less order is better...
          • Drive order via test script/scenario annotation?
  • Current Goal:
    • Big push to finish up the spec
    • Security & HA section needs amendments...

 

Thank,

Nathan

Back to the top