Question: resolvers / channel selectors UI

[Roaders]

Question Area

• [ ] App Directory
• [ ] API
• [ ] Context Data
• [ ] Intents
• [ ] Use Cases
• [x] Other

Question

Looking at the messages in BrowserTypes there are messages related to Iframes and moving or dragging iframes.

Is it a requirement of the proposed spec that UI elements are presented in an Iframe? That seems to me like it would be an implementation detail. We imagine that the Proxy agent will just add a popup to the dom with no need for an iframe.

I am also not sure why the root agent needs to know when the UI is resized or dragged.

Is there any documentation around this and why this is included in the spec?

[kriswest]

It is upto the desktop agent and app between them to determine if an intent resolver or channel selector is needed. In the connection flow, an app can indicate it doesn't need one, and a DA can indicate the iframe URLs if it is providing one. The reason that this approach is used is that we are aiming at common client code (getAgent) that will work across different DA implementations and the DAs usually want to provide the UIs - i.e. there is no proprietary library with the UIs imported into the apps. Where we to support arbitrary injection of code for the popups we would be creating a great honking (technical term) security hole in that anything could pretend to be a DA, load up an app and inject arbitrary code into it. Whereas, using the iframe approach the UI code is sandboxed away from the app, but must be communicated with through (standardized messaging). That messaging has to include the communication for dragging the iframe around (mouseevent happen inside the iframe, but the proxy needs to actually move the frame, hence the message exchanges). The same applies on resize (popping open a collapsed channel selector) as its the proxy code that needs to resize the iframe, while the UI implementation probably needs to provide the sizes (we have some refinement to do on those messages as per https://github.com/finos/FDC3/issues/1302 - I'm out for 2 weeks so it'll happen after the 19th Aug most likely).

If the apps are themselves loaded into iframes theres nothing stopping the DA from displaying these UIs another way (e.g. a titlebar rendered above the iframe can include a channel selector, an intent resolver can be displayed over the top) at which point no URLs need to be provided and the proxy code should inject no iframes. it was important to have both approaches available so we're not restricting how you go about implementing a browser-based DA more than necessary ;-)

Does that explain it all? If so please close the issue, otherwise let me know any further thoughts. I am aiming to document all of this within a few weeks on my return for the docs PR!

[Roaders]

Thanks for the quick response. I actually thought you were on holiday already so wasn't expecting you to reply so fast.

You say:

there is no proprietary library with the UIs imported into the apps

are you specifically referring to UI elements only here? This has led me to wonder where getAgent and the DesktopAgentProxy implementation come from. I assumed that these would come from an import from fdc3:

import { getAgent } from "@finos/fdc3";

We are planning on providing UI elements as part of our DesktopAgentProxy (it will be replaceable if desired) that will be part of the compiled iframe app. A developer will place the channel selection component wherever they want within their app and there will be no need for iframes.

I assume that this is supported and ok? The iframe option is only if the proxy does not provide UI and the DA needs to somehow display some UI in the attached iframe or child window without injecting code.

Thanks again. Have a good holiday.

[kriswest]

HI @Roaders, yes the getAgent and the DesktopAgentProxy would be imported from the @finos/fdc3 library (open-source non-proprietary). Part of the goal is to be able to the necessary UIs through that from the Desktop Agent without any additional integration. The options available though it to provide and intent resolver or channel selector UI include:

1. Apps indicate they want them (don't set the flags false when connecting), DA sends back URLs, Desktop Agent Proxy creating iframes and loads them with the URLs
2. Apps indicate that they don't want them (set flags false), then provide their own UIs which can directly use the FDC3 API in their implementation, e.g.
   • intentResolver: use findIntent to check for resolution options, then raiseIntent and set the app argument to the chosen option
   • channelSelector: use getUserChannels to get data to render, joinUserChannel, leaveUserChannel and the new addEventListener function to listen for external channel changes)
3. DA loads apps in an iframe, so it can display a channel selector and intent resolver outside of the iframe, so it doesn't bother to provide URLs for the DesktopAgentProxy to inject.

I think what you describe is related to 2. If so I would advise that you use the FDC3 API itself to implement those UIs if you want them to work in other standards-compliant desktop agents (either browser or container). However, if you are also implementing your own DesktopAgentProxy according to the what we're written up for the opensource implementation you can go other ways with it and you can of course just detect you are runnign in someone else's DA and change how you handle things.

I actually thought you were on holiday already so wasn't expecting you to reply so fast.

I'm supposed to be, but packing gets boring ;-)

[kriswest]

To further clarify the proprietary library comment: What I mean is the goal is to avoid having to have a specific DA-libraries incorporated into app to provide the UIs as that doesn't help us build an FDC3 ecosystem, but rather a more factional one. There is always the option for an application to provide its own UIs, but we also want to support ways for a DA to provide them, without the direct software integration.

In your case you are working on both the apps and Desktop Agent. However, if you are going to bring other firm's apps into your DA you'll need a secure means to provide them with the UIs and if your apps are used in a different DA, then you need a means to receive their UI (or to indicate that you've got it handled).

I hope that helps explain!

[Roaders]

Great, thanks Kris