kriswest
commented
1 day ago Hi @Davidhanson90
Is my understanding correct that this dependency on the root application is by design for FDC3 Web?
To a certain extent, yes. FDC3 is based on the concept of a Desktop Agent that facilitates communication, rather than peer-to-peer communication between applications. The agent concept is useful for actions like launching and intent resolution (inc. launching apps to resolve intents) as it's a single entity that is aware of what is available. It's also helpful where you have apps from a diverse set of vendors as each only has to deal with connecting to and dealing with an agent rather than many peers, resulting in fewer conversations about who each is willing to interoperate with and (perhaps) better loose coupling.
Has there been any consideration for implementing a more peer-to-peer (P2P) based protocol to enhance resilience and ensure functionality remains consistent, even if the root application is closed? Is there existing guidance on how these UX-related problems should be tackled
There was indeed consideration of how you might build a more resilient agent - particularly based on a Shared Worker. When connecting to a DA the connection flow allows you to either set up a MessagePort with a parent window or frame OR for the parent to give you a URL for an adaptor to load into an iframe, to be communicated with via a MessagePort again using the same protocol. In the early conversations, we were expecting the iframe approach to be used by implementations with a SharedWorker. The SharedWorker would be the Desktop Agent and hence would persist while any window remained connected to it - ideal! However, during the process, the Chrome Security team and others started preventing cross-domain iframes (iframes embedded into a window from another domain) from sharing workers, throwing a significant spanner into the works.
However, the adaptor approach remains and it may still be possible to build a more resilient agent using a service worker... Albeit not with the Broadcast channel API as that too was restricted in cross-domain iframes (see the note on https://developer.mozilla.org/en-US/docs/Web/API/Broadcast_Channel_API). It certainly is possible with a service or websocket (the iframes can communicate with that even if they can't communicate with each other) that is outside the browsers scope (i.e. some local executable or remote webservice). However, information on (for example) trading activity passing through the web and a third-party webservice is not always desirable/allowed, where local interop may be. One other approach I've mused on is using the page lifecycle API to catch the parent being closed and to turn over operations (and state) to one of the adaptors loaded into another app and have it act as the DA - this would rely on the ability to re-ship MessagePorts received from other apps using postMessage (something I haven't tested ad can't find anything in the HTML spec saying it is or is not supported: https://html.spec.whatwg.org/multipage/web-messaging.html#message-ports).
The fact that we have to handle cross-domain communication is what makes this difficult. window.postMessage and MessageChannels are supposed to be the best way to achieve that, but you still have to handle discovery (of other apps or the agent) and launching. Discovery is easy with a parent window or frame (enumerated frames, parent window.frame references) and launching/intent resolution is easy if one entity knows what can be launched and what is already running, which ties back to the centralized Desktop Agent concept...
Happy to pop this on the agenda for the next web browsers meeting for further discussion or to keep exchanging idea of how more resilient DAs could be built. It would definitely take some thought to come up with a viable option. On the otherhand, you can intercept window closing and warn the user what the effect of closing the parent window will be (and perhaps even the identify what apps would be affected). We don't actually have a notification to apps when the DA goes away in the connection protocol (interop will just stop/hang) although there is one for apps closing and letting the DA know (+ heartbeats).
Davidhanson90
Question Area
Question
I am currently exploring the FDC3 Web implementation and have some concerns regarding the communication flow and its resilience, particularly when the root application is closed. Here's a breakdown of the scenario and my understanding:
Current Workflow:
Root Application: Accessed via
myrootdomain.com, acts as the primary container and root agent for all communications. Child Applications: Two applications can be launched from the root: ChildA:childADomain.comChildB:childBDomain.comCommunication Process:
Issue Encountered:
Transient Nature of Web Apps: If the root application (myrootdomain.com) is closed, which is a common scenario given the transient nature of web applications, any subsequent attempts to perform the same action from ChildA fail. This is because the root, which acts as the intermediary, is no longer available to route communications.
User Experience: From a user's perspective, this results in an error or a failure in functionality that previously worked, leading to confusion and a poor user experience.
Questions:
Suggested Enhancement:
Consider P2P Communication: This could potentially allow direct communication between ChildA and ChildB without dependency on the root application, thus improving resilience and user experience.
Service workers Possibly leverage service workers for routing?
I have done no research on these suggestions so take with a pinch of salt. I am looking to the community for insights on this and any potential roadmap towards enhancing the communication framework within FDC3 Web.