Question: Disposal/Teardown patterns in FDC3

[Davidhanson90]

Question Area

[X ] Other

Question

I am looking at the concept of a multiple agents to single window proposal. I am considering that applications can be loaded and unloaded. I had a previous discuss with @kriswest who pointed me to the getAgent working document. I am wondering what spec support their is for destroying agents? if there is no clear guidance on this, are there other patterns which could be referenced such as channel teardown? Note, I did take a look at the channel types and could not find the equivalent of destroy or dispose.

[kriswest]

I don't think we've discussed this properly yet, added to tomorrows meeting agenda:

• https://github.com/finos/FDC3/issues/1267

[kriswest]

FYI Channel listener, intent listener and event listener subscriptions are all covered by the Listener object (and its unsubscribe() fn) returned by the relevant add*Listener function. We did do some basic thinking about tear down in FDC3 for the web (contrary to what I said above) - a DA could poll a particular property on MessagePorts to see if they are still alive (catching window closes and crashes) but we have yet to add a specific disconnect message (perhaps tied to an onBeforeUnload handler in the client library code. THats something we shoudl think about!

[kriswest]

Notes from SWG meeting 22/08/24:

• There was some discussion of background to this issue (raised by @Davidhanson90), including how containers (the traditional focus of FDC3) haven't needed any explicit tear-down calls as they tend to create connections on the opening of a window and then clean up when the observe it closing.
• There was consensus that there is not a clear use case for disconnect() call or similar for conventional FDC3 use.
• However, there is a clear need in web browsers as Desktop Agents can't as easily observe that a window is closed/has closed. It is to listen for a MessagePort closing, but the event may not fire if a render thread crashes, hence, implementations should periodically check the port is still working.
  • A goodbye message should be added to the Web Connection Protocol to handle tear-down and the client code can call it automatically via onBeforeUnload - however implementors would still be advised to retain instance details for apps as they may reconnect quickly, e.g. after a navigation event.
• Further, #1250 is intended to solve for cases where there may be multiple 'apps' or 'widgets' within a single page, and each needing to ahve a distinct identify in FDC3 so that they can interoperate with each other as well as other applications via FDC3.
  • It is logical to assume that they will come and go, implying the need for a teardown or disconnect API call in that use case. Hence, this should be added to the proposal for #1250.
  • @openfin-johans asked us to confirm that there are stated use cases for #1250 - @kriswest and @novavi reported that 3 firms had come to the FDC3 for the Web meetings describing their need (and efforts to build out) this use case.
  • There was consensus that it might be difficult to get #1250 into FDC3 2.2 due to time constraints - and discussion for producing a 2.3 version afterwards at a faster cadence than previous releases (FDC3's release cadence is not specified).

WCP6Goodbye added for disconnection 56a41bb0d7a866309d3e0d851caa9a70e6ee27e5 @Roaders @robmoffat