kriswest
commented
1 month ago At present, links between the AppD part of the FDC3 standard and the API part are weak (Desktop Agent API implementations are supposed to get their config from AppD) and unidirectional
Weak link between AppD and API in compliance docs:
An FDC3 Standard compliant Desktop Agent implementation SHOULD:
- Support connection to one or more App Directories meeting the FDC3 App Directory Standard.
Unidirectional:
- API implementations use AppD records to gather metadata about an app (start URL, display name, logos) and its interop capabilities (what intents does it listen for and what context types are accepted).
- There is no specified way for the AppD implementation to receive anything back
Do we support this data changing during the lifetime of the app? If I open an instrument apples then navigate to bananas when the intent resolver opens does it still describe the app as apples or has it been updated to bananas?
In short, no. It is assumed that the app always remains the same app with the same capabilities, independent of the context it is currently displaying. Were it to be navigated (to a different URL with the DOM reloaded) and it becomes a different app, fdc3 for the web will notice and re-register it as a different app. However, there is currently no specified or required method for preload DAs to do so. There is an issue open to look into that: https://github.com/finos/FDC3/issues/1339 But thats apps changing identity, rather than data in the appD changing - although that seems relevant to your question.
Roaders
Question Area
Question
This might be answered in the docs (but I think I've read most of the docs so I probably would have come across it at some point) but I wondering how app instance metadata gets from an app (here I am thinking of an app running in a different browser window communicating with the DA via the DesktopAgentProxy and the communication protocol) back to the app directory (which I assume is owned by the DA).
I am thinking specifically of
title(although now looking at the docs this is not an instance field). I am thinking specifically of text that will uniquely identify different instances of one app. For example if I have a 'view instrument' app I might have several open identified with the name of the instrument that the app is displaying.How does the display name for the instance get from the instance to the app directory so when we display an intent resolver UI we can differentiate the different app instances.
Do we support this data changing during the lifetime of the app? If I open an instrument apples then navigate to bananas when the intent resolver opens does it still describe the app as apples or has it been updated to bananas?