[WIP] 544 desktop agent bridging proposal

[kriswest]

Work-In-Progress PR for the desktop agent bridging proposal - raised to enable review and collaboration.

resolve #453

[netlify[bot]]

✅ Deploy Preview for lambent-kulfi-cf51a7 ready!

Name	Link
🔨 Latest commit	3202af54c452315d5a40a78d5a45f13e79410ce3
🔍 Latest deploy log	https://app.netlify.com/sites/lambent-kulfi-cf51a7/deploys/6358fe0b9af0f1000ac1b61f
😎 Deploy Preview	https://deploy-preview-634--lambent-kulfi-cf51a7.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site settings.

[Vivek-NatWest]

Channel State Synchronization step need a bit more elaboration for below scenario: 1- DA would async connect with bridge in background without blocking users to use interop in its context. How would this impact multiple desktop agents channel state synchronization.

• behaviour of channel.getCurrentContext in case both desktop agents have channel state for same context type but with different value for example channel1 in both have fdc3.instrument but one is for apple and other for msft.

[kriswest]

@Vivek-NatWest

• behaviour of channel.getCurrentContext in case both desktop agents have channel state for same context type but with different value for example channel1 in both have fdc3.instrument but one is for apple and other for msft.

I believe this is covered in the last two paragraphs of Step 6 of the connection protocol (connectedAgentsUpdate message):

Handling by the Desktop Agent of these synchronization messages from the DAB should be atomic to prevent message overlap with fdc3.broadcast, channel.broadcast, fdc3.addContextListener or channel.getCurrentContext. I.e. the connectedAgentsUpdate message must be processed immediately on receipt by Desktop Agents and updates applied before any other messages are sent or responses processed.

Similarly, the DAB must process handshake messages and issue connectedAgentsUpdate messages to all participants (steps 3-6) atomically, allowing no overlap with the processing of other messages from connected agents.

(n.b. I slightly improved some clumsy copy in the first paragraph before replying).

If that doesn't resolve this for you let me know and we can discuss a further change to clarify.

[Vivek-NatWest]

@Vivek-NatWest

• behaviour of channel.getCurrentContext in case both desktop agents have channel state for same context type but with different value for example channel1 in both have fdc3.instrument but one is for apple and other for msft.

I believe this is covered in the last two paragraphs of Step 6 of the connection protocol (connectedAgentsUpdate message):

Handling by the Desktop Agent of these synchronization messages from the DAB should be atomic to prevent message overlap with fdc3.broadcast, channel.broadcast, fdc3.addContextListener or channel.getCurrentContext. I.e. the connectedAgentsUpdate message must be processed immediately on receipt by Desktop Agents and updates applied before any other messages are sent or responses processed. Similarly, the DAB must process handshake messages and issue connectedAgentsUpdate messages to all participants (steps 3-6) atomically, allowing no overlap with the processing of other messages from connected agents.

(n.b. I slightly improved some clumsy copy in the first paragraph before replying).

If that doesn't resolve this for you let me know and we can discuss a further change to clarify.

Thanks @kriswest for replying.

Does this mean fdc3Ready event would not be fired by desktop agent until its connected to bridge? What would happen if there is no bridge running?

If there is no operations allowed till DA connects to bridge, would channels state contain Context JObjects (think not since channel has no history until any context broadcast happens over it?).

Also, would DAB update its channels state if it receives a channel not previously seen during broadcast? This state would be posted only on new DA connection/ disconnection?

[kriswest]

Does this mean fdc3Ready event would not be fired by desktop agent until its connected to bridge? What would happen if there is no bridge running?

No, the bridging specification as currently written is not intended to have DAs configured to require connection. Rather, they should be able to connect to a bridge as they start up or after they are running - which will make disconnect/reconnect events (e.g. because the bridge crashed) easier to handle. Once they are connected, they need to take the bridge into account during FDC3 API calls.

Hence, fdc3ready should fire when the DA is itself ready, independently of a bridging connection. However, the implementation of certain functions and connection steps do need to be handled atomically (both in a DA and the DAB) to avoid certain issues. This would be achieved differently depending on the implementation language...

If there is no operations allowed till DA connects to bridge, would channels state contain Context JObjects (think not since channel has no history until any context broadcast happens over it?).

I think we have to assume that channels may contain state when a DA connects. This could be down to a number of reasons, for example:

• The bridge crashed and was restarted, the DA has remained running
• State is being stored in a workspace or similar and restored by the DA
• Bridge instances on another machine are added to your cluster and bring state with them (resolving that would be an internal concern of the bridge implementation)

Also, would DAB update its channels state if it receives a channel not previously seen during broadcast? This state would be posted only on new DA connection/ disconnection?

It should yes. For both app channels and user channels it might be possible for connecting DA to have state on those channels (and channels themselves) that have not yet been seen. It should take on their state, merge it into the current set and then redistribute that out to other agents via the connectedAgentsUpdate message.

I think this also applies to your multi-machine implementation when a node is added to the cluster - you might bring channel state with you that has to be merged, along with additional agents...

I think the proposed sync procedure is workable and (probably) necessary. However, I'm not currently implementing this in a bridge as you are. Hence, if you foresee problems or believe a simplified procedure or simplifying assumptions are warranted then we should discuss that and make changes. If its a major change then probably the best way to kick that off is to raise an issue suggesting a change, which we'll discuss at the next meeting and have participants vote on.

[kriswest]

Closing PR as this branch has an accidental reversion of some 2.0 commits. Will reopen on a clean branch

[kriswest]

Recreated as PR:

• #860