New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[WIP] 544 desktop agent bridging proposal #634
Conversation
* meeting draft * doc cleanup * Kris tweaks: includes a new preamble. Moved apps to the end and worked on fdc3.open logic Co-authored-by: Tiago Pina <tiago.pina@cosaic.io>
544 desktop agent bridging proposal from Cosaic
Updated AppMetadata
…com/ChartIQ/FDC3 into 544-Desktop-Agent-Bridging-Proposal
Updating 544 desktop agent bridging proposal
Channel State Synchronization step need a bit more elaboration for below scenario:
|
Improving a poorly worded sentence
I believe this is covered in the last two paragraphs of Step 6 of the connection protocol (connectedAgentsUpdate message):
(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 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? |
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,
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:
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 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. |
update TODO list
…posal typos and linting
Closing PR as this branch has an accidental reversion of some 2.0 commits. Will reopen on a clean branch |
Work-In-Progress PR for the desktop agent bridging proposal - raised to enable review and collaboration.
resolve #453