Question: Proposed getAgent() implementation. How to get an agent with a different id and instance to parent

[Roaders]

Question Area

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

Question

As discussed at length (thanks very much @kriswest ) in other issues I now understand that for the web one possible FDC3 implementation is to have a container window with one Desktop Agent (DA) and to have other windows (or Iframes) that have different instances of the API. The DA in the container and the other api instances can be considered to be one Agent that is split up into different parts and communicate over the proposed communication protocol.

I also understand that the proposed getAgent() implantation will attempt to resolve an agent from either window.fdc3 or window.opener.fdc3 or other variations on this.

In the case that an agent is resolved from a parent window how would a child window obtain a copy of the API that would have the correct appId and a new instanceId?

I understand that if for example an electron container creates a new window and injects the API then it can create a new instance with a new instance Id and inject that but if we're just copying the agent from the parent I can't see how that would work.

[Roaders]

ok, I've read the proposal now and see that my understanding of what it does is incorrect. In the case where an agent in a parent window was found it does not return that. Instead it creates a proxy and sets up communication between the proxy and the parent container.

[Roaders]

Actually, having read the proposal it doesn't seem to require that the getAgent() function sets the acquired or created agent to window.fdc3. Does that need to be added or did I just miss that (I was having to read it on my phone so not the easiest reading experience).

[kriswest]

Instead it creates a proxy and sets up communication between the proxy and the parent container.

Yes, because browser sandboxing would prevent code being transferred between the windows and it did not seem appropriate to enable code injection (or rather a system where the FDC3 module code downloaded and injecting code) in a browser as that create security holes. However, there is the option to create a hidden iframe and load code into that, which maintains sandboxing between the injected code and the page its injected into. Fortunately, you can use exactly the same protocol and web APIs to talk to that iframe as you could a different window. Hence, theres some flexibility in how you build your agent.

Actually, having read the proposal it doesn't seem to require that the getAgent() function sets the acquired or created agent to window.fdc3. Does that need to be added or did I just miss that (I was having to read it on my phone so not the easiest reading experience).

We've gone back and forth on whether getAgent should accept an option that causes it to do that for you. Personally, I think it simpler to just add one extra line of code if you are retrofitting an existing app that uses window.fdc3:

const fdc3 = await getAgent(... args ...);
window.fdc3 = fdc3;

Please note that the proposal doesn't actually have you access window.opener.fdc3, rather it will window.opener.postMessage to retreive a MessagePort (see https://developer.mozilla.org/en-US/docs/Web/API/Channel_Messaging_API/Using_channel_messaging for more details) and then communicate with it over that. The reason for that is that sandboxing will prevent you from accessing the scope of the other window (unless you are same origin and in the same render thread).

P.S. if you like a copy of the proposal emailed to you let me know. I'll be working on the docs additions for it over the next few weeks so there should be more detail in PR and preview of the FDC3 site when done.

[Roaders]

So in that case there would be no window.fdc3 set and no event fired for any old school code that relies on that? Does this mean that spec would change to no longer require that window.fdc3 MUST be set?

If there are multiple disparate components that all call getAgent() they could all get a different instance of the proxy each with it's own communication channel to the parent.

Thanks for the clarification. Feel free to close.

[kriswest]

So in that case there would be no window.fdc3 set and no event fired for any old school code that relies on that? Does this mean that spec would change to no longer require that window.fdc3 MUST be set?

Correct, unless they retrofit with that extra one line when adding in getAgent(). As it stands, those apps wouldn't be able to use FDC3 in a web browser without at least the getAgent() change anyway as FDC3 has relied on the injected API up until this point. While Desktop Agents MAY support other ways to get the API, those techniques are inherently vendor-specific (e.g. importing a library supplied by a vendor) and defeat the purpose of having a common API Standard, which is to help develop an ecosystem by allowing apps to write to the standard and run under any Standard conformant agent.

If there are multiple disparate components that all call getAgent() they could all get a different instance of the proxy each with it's own communication channel to the parent.

I think thats true, yes - but doesn't work for the container cases, hence the 'sub-application' proposal.

[Roaders]

After more consideration it looks like the getAgent() approach will solve a lot of the issues that we were going to have to solve ourselves anyway. We are planning to implement this using the proposal in the document you shared. We will offer this for contribution when it's done. I realise that it's just a proposal at the moment that might change but we'd be doing very similar implementation steps anyway so we may as well follow the proposal. How do I ensure that I included on future discussions of the propsal?

[kriswest]

@Roaders that's great news.

To have any FDC3 meeting added to your calendar simply drop an email to help@finos.org and ask to be added to the invite for it. In this case its 'FDC3 for Web Browsers discussion group meeting'.

We'll be moving from the proposal doc to working in a (non-draft) PR soon, once done I'll make sure I share the details.

[robmoffat]

Hi @Roaders,

Early POC work on getAgent is happening here: https://github.com/finos-labs/fdc3-for-the-web

If you'd like to get involved and contribute some code then maybe you can set up a calendar invite with me? https://calendar.app.google/TrnobbJCn29vFoX27

Very happy to have your help!

Rob