Open robmoffat opened 1 year ago
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.
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...
@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.
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
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.
...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.
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.
postMessage
for FDC3 on the Web, or Async API via WebSockets
(in the case of Desktop Agent Bridging)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.
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.
Enhancement Request
In a recent email on the FDC3 mailing list, @kriswest wrote:
and:
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.