Skip to main content

PROTOCOL

Constant PROTOCOL 

Source
pub const PROTOCOL: Version;
Expand description

The protocol version this SDK speaks.

Independent of the daemon’s version, which is the whole point of FR-049: an addon is built against an SDK, not against a daemon, and the two ship separately. major differing means incompatible, and the daemon refuses rather than loading — FR-049 again, with a message naming the fix, the same rule the UI–daemon handshake already follows.

§1.1 — device-resolved actions

Description::device_actions was added (ADR-0021). Minor, because Version::compatible_with compares majors, the field is omitted when empty, and an addon that declares none puts not one new byte on the wire. A major bump would refuse every 1.1 addon on a 1.0 daemon — the shipped ones, and every third-party addon that declares nothing of the kind — to defend against one field.

Additive on the wire is not additive in meaning, and the version number cannot carry the difference. Two things carry it instead, and neither is optional:

  • A daemon that reads this field must refuse an action it cannot represent, naming it, rather than reading it as something else. The refusal is per action: the addon stays in the registry with that one row reported unusable. Failing the handshake instead would leave the addon nowhere but a log line, which is a Principle IV collapse — and it is why KeystrokeDecl carries KeystrokeDecl::Unknown rather than failing the parse of the whole Description.
  • A daemon built against 1.0 does not know the field exists. Serde drops what it does not recognise, so it will send Request::Perform for an action whose author never wrote a perform arm. run answers that itself with a failure naming the cause, rather than letting it fall through to NoSuchAction, which would send the user looking for a missing action that is right there in the list.