Goal
Prove the spec is portable, not an accidental description of the C# implementation.
A second compatible implementation forces the spec to be precise. Promoted out of Phase E because it's a multi-week engineering effort (new package, new CI lane, cross-implementation interop tests), not a developer-guide doc.
Concrete shape
Python is the obvious second language - large amateur-radio Python community, easy onboarding. Aim for:
- A minimal
dapps-py that implements the on-air protocol (DAPPSv1 codec + parser) and the AGW transport.
- Talks to the same
m0lte/linbpq Docker image we use in CI today.
- Cross-implementation interop test in CI:
dapps.core (C#) on one side, dapps-py on the other, message goes through end-to-end.
The implementation does not need feature parity with dapps.core - it only needs to be interop-correct. Subset of MQTT/REST app interface (probably MQTT only), no dashboard, no auth, no persistence (in-memory queue is fine for an interop tester). The point is to surface ambiguities in the spec by forcing a second author to read it and implement it.
Pickup signal
When the protocol has been exercised enough by first-party apps that the ambiguities are likely to surface but it's still tractable to align two implementations. Roughly: after the developer guide has been used by external authors and we've taken at least one round of clarifying spec edits.
Migrated from plan.md Phase G (not-yet-prioritised).
Goal
Prove the spec is portable, not an accidental description of the C# implementation.
A second compatible implementation forces the spec to be precise. Promoted out of Phase E because it's a multi-week engineering effort (new package, new CI lane, cross-implementation interop tests), not a developer-guide doc.
Concrete shape
Python is the obvious second language - large amateur-radio Python community, easy onboarding. Aim for:
dapps-pythat implements the on-air protocol (DAPPSv1 codec + parser) and the AGW transport.m0lte/linbpqDocker image we use in CI today.dapps.core(C#) on one side,dapps-pyon the other, message goes through end-to-end.The implementation does not need feature parity with
dapps.core- it only needs to be interop-correct. Subset of MQTT/REST app interface (probably MQTT only), no dashboard, no auth, no persistence (in-memory queue is fine for an interop tester). The point is to surface ambiguities in the spec by forcing a second author to read it and implement it.Pickup signal
When the protocol has been exercised enough by first-party apps that the ambiguities are likely to surface but it's still tractable to align two implementations. Roughly: after the developer guide has been used by external authors and we've taken at least one round of clarifying spec edits.
Migrated from
plan.mdPhase G (not-yet-prioritised).