Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[sparkplug-dev] Eclipse Sparkplug Specification Project - Meeting Notes - 06 October 2020

Hi all,

 

Please find the Eclipse Sparkplug Specification Project meeting notes from today’s meeting below.

 

Eclipse Sparkplug Specification Project - Meeting Notes - 06 October 2020 

  • Attendees: 
    • Wes Johnson
    • Chad Kienle
    • Ilya Binshtok
    • Dominik Obermaier
    • Ivar Grimstad
    • Frederic Desbiens
    • Josh Wolf
    • Nathan Davenport

  • Ivan Grimstad joins us for some Q & A. Thanks Ivan! [Recorded]
    • How are specifications developed and managed in Jakarta EE? 
      • Using the mvc-api project as an example...
        • The specification is organized in separate chapters. Generally there is single committer organizing the effort and asking for committers to own sections/chapters of the specification document. Single owner per section(s) during the process, results in less merge conflicts.
        • The specification is in AsciiDoc format.
        • The specification chapters contain annotations for testable components. 
        • The specification annotations are transformed (via .XSL file) to XML that can be more easily consumed by the TCK.

 

      • Assertions? MUST, MAY/optional? 
        • May be able to use the XSL (modified) to generate separate XML files to be consumed by the TCK...
          • One set of assertions for MUST that everyone must adhere to 
          • Another for the full set of assertions (MUST, MAY/optional, etc.)
        • Avoid MAY / optional assertions... they can become cumbersome to manage in the future. 

  • Nathan Davenport nominated to be the meeting minutes recorder for our meetings going forward.

  • Status Update (from last meeting):
    • Roadmap document created and merged into /doc [Wes] 
      • Eventual ranking of features
      • Votes for tracking interest
    • Normative statements document created and merged into /doc [Wes]

  • Reviewed Dominik Obermaier’s reworking of the Sparkplug specification structure (similar to MQTT spec) to help with normative/non-normative statements
    • How do we share these types of ideas especially if there will be no PR at any point?
      • Slack is probably the best way to do this.
    • Dominik shared the outline of the reorganized Sparkplug specification on the call. [Recorded]
      • Core part of the specification, not specific to A, B, C and then “amendments” on top of the core for A, B, C?
      • Separate data specs would be good?
      • What about High Availability? 
      • How long will it take us to get the specification updated, including any reorganization? ~1 month
      • Store and Forward needs to be covered in the specification.

  • Next Steps
    • Dominik to share his re-worked spec outline via a PR [Dominik]
    • Start breaking out sections and figure out how to assign out work [*]

  • Video recording of the meeting: https://drive.google.com/file/d/1GT6weKo0OWn5IwNUKRCvySfFF971jN8j/view?usp=sharing  

  • Notes
    • Don’t forget the -s on your Git commit!
    • We will record meetings going forward.

 

Thanks,

Nathan Davenport

Back to the top