SRM Notes for 30-01-2025

[bruno-f-cruz]

Agenda

• 🚀Small Issue (10 min)
• 🚅Medium Issue (20min)
• 🐢Large Issue (45min)

Reviewing

• Add heartbeat enable flag #67 -> Clarify the backwards "compatibility-ness" 🚀
• Add semantic version register #68 -> Decide how to track SDK list 🚅
• Define a data logging/ingestion format and spec #41 -> What doc should be added to harp-tech website and to the "protocol" repository 🚅
• State of pyharp library

New

• Add R_TIMESTAMP_OFFSET register to schema #23 -> Decide on the fate of this register. Probably just an initial discussion. 🚀

[bruno-f-cruz]

For #68:

• @PathogenDavid suggests making the SDK identifier a fixed length string to make it easier to know what SDK we are using without checking a centralized source of the enums. This would not preclude pre-registering the SDK strings. Is this a problem in terms of storage?
• Consider making it 5 bytes of char instead of 1 byte.

[bruno-f-cruz]

Regarding logging, the idea is to include a new markdown file in the protocol repository that describes the logging standard. This md file will be rendered with the remaining standard specs in the harp-tech website.

[glopesdev]

@PathogenDavid suggests making the SDK identifier a fixed length string to make it easier to know what SDK we are using without checking a centralized source of the enums. This would not preclude pre-registering the SDK strings. Is this a problem in terms of storage?

I realised one issue with this approach is that the register payload becomes heterogeneous (a string or character array in the middle of a byte array). While this is not theoretically a problem, in practice will require handling at different levels (client, harp-python, etc) so that people actually can read the decoded characters.

Again not a problem, but since we don't have yet a final generic solution for heterogeneous types (and especially no built-in solution for strings or character arrays, which are not a native payload type), I think I still prefer the current proposal of using a single byte for this.

We can reserve the default value zero for "custom" or "experimental" SDKs, and in that case we could add information to the TAG register about what it is.

I don't think we will have issues with proliferation of custom harp SDK implementations and definitely not nearly as much as we have with custom device IDs. Especially with SDKs I think it is even more important to have a central register of them, since they will directly impact guarantees across all aspects of the entire ecosystem (synchronization, latency, etc).

[bruno-f-cruz]

Feedback from SRM Notes for 06-02-2025

This change requires a specification to be written if we are going with string-based ids. Specifically:

Add a string "specification" in the device.json/yml. This should be documented as following utf8 (no terminator, nulls illegal). This should probably be something that goes into the "payloadSpec".

This change must trickle down to:

• Document in the protocol that this is the standard for strings.
• harp-python API (which is already breaking with the DeviceName register)
• bonsai code generators (parsers should be able to unpack to this value)

Consider changing, in https://github.com/harp-tech/protocol/blob/main/schema/registers.json, InterfaceType to an Enum(?). This would allow parsing byte[] to strings. Should these be Enums in the schema or just enums as a community standard?