Problem
In ldp-protocol, PayloadMode.SEMANTIC_GRAPH exists in the enum but is_implemented returns False. This means negotiate_payload_mode() will never select Mode 3, even when both parties declare support for it.
Any client using negotiate_payload_mode() directly (which is the expected path) can't discover or negotiate Mode 3 capability.
Current workaround
In flowscript-ldp, our FlowScriptMode3Delegate overrides _handle_session_propose() to bypass the is_implemented gate entirely. The delegate knows it IS the implementation, so it checks the initiator's supported modes directly and negotiates SEMANTIC_GRAPH when both sides support it.
This works, but it means Mode 3 negotiation only succeeds when our delegate handles the session proposal. Any generic LDP client or router that calls negotiate_payload_mode() won't see Mode 3 as an option.
Proposed approaches
Option A: Flip the flag. Set is_implemented = True for SEMANTIC_GRAPH now that a reference implementation exists. Simple, but arguably premature if the spec wants to gate on multiple implementations or a conformance test.
Option B: Registration mechanism. Let implementations declare support at runtime:
PayloadMode.register_implementation(PayloadMode.SEMANTIC_GRAPH, "flowscript-ldp")
This keeps is_implemented accurate to the local environment. It returns True only when something is actually installed that handles it. More work, but more correct.
Option C: Remove the gate from negotiation. Let negotiate_payload_mode() consider all modes that both parties declare, regardless of is_implemented. Implementations that can't actually handle a mode simply shouldn't declare it. The is_implemented flag becomes informational rather than a hard gate.
I'd lean toward B or C, but happy to go with whatever fits the SDK's design direction. Can submit a PR for whichever approach you prefer.
Problem
In ldp-protocol,
PayloadMode.SEMANTIC_GRAPHexists in the enum butis_implementedreturnsFalse. This meansnegotiate_payload_mode()will never select Mode 3, even when both parties declare support for it.Any client using
negotiate_payload_mode()directly (which is the expected path) can't discover or negotiate Mode 3 capability.Current workaround
In flowscript-ldp, our
FlowScriptMode3Delegateoverrides_handle_session_propose()to bypass theis_implementedgate entirely. The delegate knows it IS the implementation, so it checks the initiator's supported modes directly and negotiatesSEMANTIC_GRAPHwhen both sides support it.This works, but it means Mode 3 negotiation only succeeds when our delegate handles the session proposal. Any generic LDP client or router that calls
negotiate_payload_mode()won't see Mode 3 as an option.Proposed approaches
Option A: Flip the flag. Set
is_implemented = TrueforSEMANTIC_GRAPHnow that a reference implementation exists. Simple, but arguably premature if the spec wants to gate on multiple implementations or a conformance test.Option B: Registration mechanism. Let implementations declare support at runtime:
This keeps
is_implementedaccurate to the local environment. It returnsTrueonly when something is actually installed that handles it. More work, but more correct.Option C: Remove the gate from negotiation. Let
negotiate_payload_mode()consider all modes that both parties declare, regardless ofis_implemented. Implementations that can't actually handle a mode simply shouldn't declare it. Theis_implementedflag becomes informational rather than a hard gate.I'd lean toward B or C, but happy to go with whatever fits the SDK's design direction. Can submit a PR for whichever approach you prefer.