FDC3 For Web browsers

[robmoffat]

Enhancement Request

In a recent email on the FDC3 mailing list, @kriswest wrote:

... I also want to add that there is clearly significant interest in the community in enabling FDC3 use on the web. There is a strong use case in that it would enable better onboarding journeys with less drop-off (where you use an app on the web with others before adopting a desktop container or similar).

and:

But there are also additional challenges such as how to make the API available reliably without importing a proprietary module from a particular vendor into every app, how to deal with more than one implementation of API/Desktop Agent in the browser at once, how to do this reliably and securely within the browser sandbox etc.. Work needs to be done in the Standard to solve these issues and to make web browser use possible in a future FDC3 Standard version - which I believe is possible (and likely to involve using a vendor-agnostic FDC3 NPM module to detect and connect to API implementation(s)). However, we're going to need to do that work to enable the aforementioned API implementations to be compliant and if we fail to hold the line now on compliance with the current version of the FDC3 Standard, that may never happen.

Hence, I strongly encourage any vendors or firms working on API implementations that would fall outside current compliance requirements to work with the FDC3 maintainers and community, in general, to help move the Standard forward! The first step will be to raise an issue to bring to the Standards Working Group, which might then move to a Discussion Group to develop a proposal for additions to the Standard and its software. The maintainers meet again next week and will discuss getting such an issue on the books.

This is therefore a placeholder issue where we can begin to discuss how to solve this problem and potentially open up FDC3 to a wider audience.

[kriswest]

7. You're introducing a race condition around who is setting window.fdc3 which otherwise wouldn't exist (probably the biggest problem).

No we're not as that race has to be specifically dealt with in step 1 (in any of the proposed options).

Apologies I didn't articulate that well at all. I had exactly the same initial reaction on my initial review of Step 1 Option 1 (Race) - and is why I personally think that it's not viable and we should try and ensure that there isn't a race. Thinking on it now, it might not be solvable for apps that have integrated the installer but then get run on an older container that sets the global up late, but for newer implementations at least I think we should at least amend the advice on when to set up the global to ASAP (with queuing if you need it). As step 2 can run in parallel (its likely to be mutually exclusive with step 1 use cases), this step 1 issue affects how quickly you can move on to step 3.

As apps can set the global themselves with a single line of code (and will rarely care about the above case), it (installer setting the global) doesn't matter to me all that much. I'll update the proposal to show that instead when I have a minute.

[kriswest]

In the Desktop Agent Bridging PR we are having to add JSON Schema for all objects defined in the FDC3 API, which will then be referenced in the payloads defined in bridge message schemas. We intend to keep the two sets separate as far as possible as the API schema could be reused, for example in a postMessage based protocol for web containers.

In theory, we could switch to generating TypeScript types from these, however, quicktype sometimes generates non-ideal code (and can't build types with inheritance) so I'd recommend that we don't, instead picking up the burden of maintaining both the typescript types and schemas in parallel (which isn't all that hard once the original set have been created). It's also worth noting that quicktype seems to do a better job of going the other way and generating schema from the typescript...

[thorsent]

@nkolba I'm just getting a chance to look at the web portal code. Looks like it's along the lines that we discussed last meeting. I hope we can carve out time for you to walk the group through the project.. I haven't done a thorough review but have a little bit of initial technical feedback:

It looks like the handshake is implemented via an inbound request from opener -> child. I think there's a potential race here. It didn't look to me that browsers provide a reliable way of ensuring that a child receives a postMessage from a parent if the child sets up the listener after the fact (but I haven't experimented, perhaps Chrome is ahead of the spect, otherwise it may be necessary for the parent to poll, unless we can invent a scheme where the child posts back to the opener - though this can get complicated when there are multiple descendants).

Regarding detection of closed app boundaries - I think it would be reasonable to leave this requirement off, and out of the open-source implementation. There are probably several approaches that could be taken and vendors might choose to implement different types of reliability mods as value adds. I would be interested in the group's perspective.

[nkolba]

thanks for the feedback @thorsent

Agree with the question of app boundaries, this is best left to the implementation layer. There may be a similar conclusion we reach on race condition strategy as well....

FYI: I will have a hard stop at 11:30 EST tomorrow - @kriswest - can we have any discussion on this in the first half of the meeting?

thanks.

++ @bschwinn

[kriswest]

I think leaving the potential race unaddressed/for the implementation layer would be a mistake and very likely to cause issues and contention between desktop agent implementors.

Duly noted on the hard stop - however, I think we need to finish up what we were halfway through last time rather than jumping around. Reviewing another proposed implementation before we've agreed on requirements for one might be putting the cart before the horse.

I'm booked up before the meeting, but will post an agenda shortly and try to fit in a look myself beforehand today.

[kriswest]

...and I firmly grasped the wrong end of the stick on which potential race was being discussed 😊 (I thought you meant the race between step 1 and 2, rather @thorsent noted a potential race within the step 2 parent/child messaging).

It bears discussion - and fortunately is right where we were in the proposal review (step 2). Hence, we could probably pick up there.

[robmoffat]

So, first thing I wanted to document in here is based on chats I've had with @kriswest and @openfin-johans. I am starting to see the space we're in as a bit like the OSI stack. Recall in that different concerns are handled in different layers. I think we'd do well to adopt a similar approach here.

• So, one layer of the stack is our JSON schema for FDC3 messages. The wire protocol.
• A layer above this defines how these objects are sent around. This could be over postMessage for FDC3 on the Web, or Async API via WebSockets (in the case of Desktop Agent Bridging)
• A third layer on this might define the application itself. For Desktop Agent Bridging this might be the port ranges, retry logic, config etc.

The main advantage of this is reuse. I see us being able to reuse a lot of this in different places if we modularise correctly.

[robmoffat]

A point that I didn't raise in the meeting yesterday was that I see a pattern emerging that I think we should make sure we exploit. Which is - when we consider Desktop Agent Bridging, what @nkolba is doing with Connectifi and what Pierre is after with as @kriswest calls it "Micro Frontend Container instance sharding" we end up with quite the hierarchy of contexts:

This implies to me that we should ensure that whatever abstractions we build work at any arbitrary layer of a hierarchy.

I am going to leave this here for other people to think about rather than try and fill out any details - I'm not proposing anything per se, just saying that this needs some thought.

[kriswest]

The discussion group's working doc was migrated to Sharepoint from Google drive and can now be found here.