FDC3 For Web browsers #896
Comments
|
This is a problem with some prior art:
As @kriswest says in the quote above, he thinks there is interest within the community. I have personally talked to a number of App vendors who are confused as to why this isn't a thing already. I am hoping we can have a discussion on this at the next maintainers' meeting and move this forwards |
|
Here is my thinking so far on the subject (more to seed a debate rather than anything else).
|
|
Hi @robmoffat thanks for raising this issue. Related this this, on the point @kriswest raised (which you cited) about the possibility of using a 'vendor-agnostic FDC3 NPM module to detect and connect to API implementation(s)', I have something to share. I have implemented this https://github.com/novavi/fdc3-installer over the last few weeks. It aims to provide a solution to the problem in browser-based environments of tight coupling between FDC3-enabled apps and FDC3 Desktop Agents, by providing a mechanism to dynamically discover and install an agent within an app at runtime. This approach allows an app to run both in a desktop container (using the container's built-in agent) and also in a browser-based micro-frontend container (using a dynamically-installed agent) with zero code changes to the app. The library supports multiple strategies for the areas of agent discovery, creation and bootstrapping - with the ability to easily add and try out additional strategies based on any subsequent discussion / ideas. The library does not claim to have all the answers by any means, but demonstrates some of the options that could potentially be used for a solution in this area. I hope this will help in the wider discussion that needs to be had within the FDC3 community about how we can best overcome the tight-coupling problem for browser-based FDC3 Desktop Agent implementations - and help move us towards standardized approach in the future. I was originally aiming to publish this library more like sometime next month rather than now but after seeing that you'd raised the issue, I brought this forward in the interest of the discussion and just published what I have now. Because of this, I haven't actually even proof-read the stream-of-consciousness that I turned into a README yet, so parts of the description might still be a bit rough round the edges. |
|
@novavi many thanks for sharing your work on this issue.
While I suspect/hope we'll end up adopting a subset of what you propose, it
nevertheless represents a tour-de-force in exploring the options and
related issues. I look forward to reviewing (and hunting for the strategies
I intend(ed) to propose within your implemented set).
K
…On Mon, 23 Jan 2023, 10:08 Derek Novavi, ***@***.***> wrote:
Hi @robmoffat <https://github.com/robmoffat> thanks for raising this
issue.
Related this this, on the point @kriswest <https://github.com/kriswest>
raised (which you cited) about the possibility of using a 'vendor-agnostic
FDC3 NPM module to detect and connect to API implementation(s)', I have
something to share.
I have implemented this fdc3-installer library:
https://github.com/novavi/fdc3-installer
over the last few weeks. It aims to provide a solution to the problem in
browser-based environments of tight coupling between FDC3-enabled apps and
FDC3 Desktop Agents, by providing a mechanism to dynamically discover and
install an agent within an app at runtime. This approach allows an app to
run both in a desktop container (using the container's built-in agent) and
also in a browser-based micro-frontend container (using a
dynamically-installed agent) with zero code changes to the app. The library
supports multiple strategies for the areas of agent discovery, creation and
bootstrapping - with the ability to easily add and try out additional
strategies based on any subsequent discussion / ideas.
The library does not claim to have all the answers by any means, but
demonstrates some of the options that could potentially be used for a
solution in this area. I hope this will help in the wider discussion that
needs to be had within the FDC3 community about how we can best overcome
the tight-coupling problem for browser-based FDC3 Desktop Agent
implementations - and help move us towards standardized approach in the
future.
I was originally aiming to publish this library more like sometime next
month rather than now but after seeing that you'd raised the issue, I
brought this forward in the interest of the discussion and just published
what I have now. Because of this, I haven't actually even proof-read the
stream-of-consciousness that I turned into a README yet, so parts of the
description might still be a bit rough round the edges.
—
Reply to this email directly, view it on GitHub
<#896 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAM7PBGQKMDQ7S3S72MXK53WTZKALANCNFSM6AAAAAAUAFXPPQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
@kriswest no probs.
Yes tbh I'd be very much in favour of narrowing down to a subset of the
options if this type of approach was to be standardized. The strategies you
intend(ed) to propose might not even be amongst the ones I came up with
actually! I'm sort of hoping that there might be more options on the table
to choose from when standardizing this.
The main constraint I applied when listing out and implementing those
discovery strategies was that the container-based ones *must* work on a
cross-origin basis. I think it's sensible to make any standardized solution
work for the more restrictive cross-origin scenario, and then it will
automatically work for the (simpler) same-origin scenario. From my
experience of large organisations who hope to provide a more unified
customer experience for their existing brownfield apps, those apps are
typically built by separate teams on separate tech stacks in separate repos
with separate release schedules and deployed on separate subdomains. That
is to say, if an organisation has apps that are commonly on the same
subdomain as their container (and as each other) then they are quite
probably heavily down the road towards a module federation approach, and
may have less requirement for FDC3 interop in their apps in any case
(except perhaps for third-party app integration).
There's more freedom on the app-based discovery strategies of course,
because you don't have to worry about the cross-origin issue e.g. even
reading from a previously-defined global variable would be possible. I did
avoid a few other things like reading from meta tags e.g. that requires SSR
of the host page in order to prevent it just being a pointless exercise in
moving hard-coding from one place to another. That said, the general risk
with app-based discovery strategies (as opposed to container-based ones) is
that it could be quite easy to misuse them if one did not fully understand
their purpose (e.g. again using an installer, but simply moving hard-coding
from the app's code into the app's config).
In terms of the range of strategies supported, the whole concept certainly
becomes less usable by casual FDC3 app devs and less supportable as a
library if it aims too wide (indeed, supporting corner cases sometimes
encourages requests to support further corner cases). Laying out the
options in this library was partly intended as a mechanism to help test
them and discuss them - because without a concrete implementation it can
sometimes be hard to see the relative merits and pitfalls of different
approaches.
Having said that, it's worth pointing out that we should really distinguish
between a *generic* installer library that can load pretty much any
arbitrary browser-based FDC3 Desktop Agent *today* (which is sort of what I
just about implemented) and a future standardized installer that only needs
to load a future FDC3 Desktop Agent adhering to a future spec version (2.1
or above?) which is clear about how agents are to be provided. For example,
if a future version of the FDC3 spec mandated that an agent *must* be
provided by a factory function and exported via an ES Module with a
specific name, then one should be able to easily dispense with the
different creation strategies - although one would still need to offer
support to pass args to that function in a config of some sort (whether to
provide a WebSockets url for a cloud-based approach, or simply just more
mundane options applying to all browser-based implementations e.g. whether
fdc3.open() should open apps in tabs / windows / iframes). The issue of
bootstrapping is more involved than that of creation because as I alluded
to in the README for this repo there is (currently at least) a relationship
between agent bootstrapping and window.fdc3 installation in terms of the
overall agent lifecycle... which is a subject for another email thread I
think!
- Derek
…On Mon, Jan 23, 2023 at 12:42 PM Kris West ***@***.***> wrote:
@novavi many thanks for sharing your work on this issue.
While I suspect/hope we'll end up adopting a subset of what you propose, it
nevertheless represents a tour-de-force in exploring the options and
related issues. I look forward to reviewing (and hunting for the strategies
I intend(ed) to propose within your implemented set).
K
On Mon, 23 Jan 2023, 10:08 Derek Novavi, ***@***.***> wrote:
> Hi @robmoffat <https://github.com/robmoffat> thanks for raising this
> issue.
>
> Related this this, on the point @kriswest <https://github.com/kriswest>
> raised (which you cited) about the possibility of using a
'vendor-agnostic
> FDC3 NPM module to detect and connect to API implementation(s)', I have
> something to share.
>
> I have implemented this fdc3-installer library:
>
> https://github.com/novavi/fdc3-installer
>
> over the last few weeks. It aims to provide a solution to the problem in
> browser-based environments of tight coupling between FDC3-enabled apps
and
> FDC3 Desktop Agents, by providing a mechanism to dynamically discover and
> install an agent within an app at runtime. This approach allows an app to
> run both in a desktop container (using the container's built-in agent)
and
> also in a browser-based micro-frontend container (using a
> dynamically-installed agent) with zero code changes to the app. The
library
> supports multiple strategies for the areas of agent discovery, creation
and
> bootstrapping - with the ability to easily add and try out additional
> strategies based on any subsequent discussion / ideas.
>
> The library does not claim to have all the answers by any means, but
> demonstrates some of the options that could potentially be used for a
> solution in this area. I hope this will help in the wider discussion that
> needs to be had within the FDC3 community about how we can best overcome
> the tight-coupling problem for browser-based FDC3 Desktop Agent
> implementations - and help move us towards standardized approach in the
> future.
>
> I was originally aiming to publish this library more like sometime next
> month rather than now but after seeing that you'd raised the issue, I
> brought this forward in the interest of the discussion and just published
> what I have now. Because of this, I haven't actually even proof-read the
> stream-of-consciousness that I turned into a README yet, so parts of the
> description might still be a bit rough round the edges.
>
> —
> Reply to this email directly, view it on GitHub
> <#896 (comment)>, or
> unsubscribe
> <
https://github.com/notifications/unsubscribe-auth/AAM7PBGQKMDQ7S3S72MXK53WTZKALANCNFSM6AAAAAAUAFXPPQ
>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>
—
Reply to this email directly, view it on GitHub
<#896 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA2PIF2NEGCEAVBWP7JUIXDWTZ4B3ANCNFSM6AAAAAAUAFXPPQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
@novavi - this is great work! Thanks for sharing. Just want to note that this is a code project and exactly the kind of work that is vital to the ecosystem. It also underscores that there isn't anything missing from the standard to solve this problem. In fact, as @robmoffat alludes to, Connectifi already provides secure and seamless support across all environments including web and cross-origin in full conformance with the 1.2 spec. Keeping the standard simple, accessible, and focused only on those problems that truly address interoperability is the best way to continue to drive adoption as well as the innovation of FDC3. |
That is not the case @nkolba - it demonstrates that the problem, of establishing standardized ways of retrieving a reference to an API implementation, is solvable. It absolutely doesn't eliminate the need to adopt a standard for how to do so that app developers can write a single way of doing so/single version of their apps. Further, @novavi's write-up on it clearly indicates several areas that would specifically benefit from standardization, or already do, in order to reduce complexity for the app developer. These include the installation of the API reference into If we don't provide a clear standardized approach we are not keeping the Standard simple or accessible - quite the opposite as application vendors will still have to choose approaches, configure for individual providers, test widely etc. and hence we again encourage the ecosystem to become fragmented and factional. Whereas, with a little work we can likely reduce complexity for app developers significantly, aiming for as close to zero configuration and variation in code as possible. That is quite obviously addressing problems that affect interoperability and ease of adoption, where attempting to block the community from doing so is not. |
|
As discussed in the standards meeting last week, it may helpful to split this (and the previous email thread) into three separate topics:
Note: while points 2 & 3 are somewhat related, the global issue doesn't just impact web. It is a blocker for conformance support on other tech stacks such as Java, .NET, Python, and many others and forces FDC3 conformance into a very specific type of implementation. |
|
As discussed in the standards meeting last week, it may helpful to split
this (and the previous email thread) into three separate topics:
- Whether 1.2 Conformance tests should require FDC3 to be exposed as a global or if this should be optional (as the 1.2 spec states <https://fdc3.finos.org/docs/1.2/api/spec#api-access>)
As discussed at the meeting (and minuted), I agree that the 1.2 spec allows for the FDC3 API reference to be provided by other means (MAY), but does recommend (SHOULD) that it is provided as a global. The SWG voted to change this in 2.0 such that the global is required (MUST) as it was widely agreed that a standard way to retrieve the FDC3 API reference was essential to the Standard as a whole and its uptake with the industry.
Further, it is somewhat awkward that, in order to run the tests on a 1.2 implementation without the API being provided via window.fdc3, the test framework has to be modified with proprietary dependencies and bootstrapping code for each implementation that needs testing - providing an example of the type of challenge that this creates.
- Whether the global requirement should be continued going forward in 2.x
- What additional standards (if any) are needed for Web.
I think it an odd suggestion that these two items should be dealt with separately as both relate to the code an app developer must write in order to get at a copy of the FDC3 API. If we don't provide an answer that spans both the web and containers, then this fractures the ecosystem and is likely to result in app developers having to provide different implementations, deployments and appD records not just for browser/container deployments, but also for working with different FDC3 implementations. Whereas, if we work to move the standard forward we can provide a standardized approach that works for all cases. The value in doing so for app vendors, desktop agent vendors and FDC3 adopters is obvious - so I'll refrain from restating it here again. I have, however, yet to hear a decent argument for why not moving the Standard forward on this issue would benefit the community in any way.
Note: while points 2 & 3 are somewhat related, the global issue doesn't just impact web. It is a blocker for conformance support on other tech stacks such as Java, .NET, Python, and many others and forces FDC3 conformance into a very specific type of implementation.
This is not the case as those global requirement has always been scoped to
web applications:
API access in 2.0 <https://fdc3.finos.org/docs/api/spec#api-access>:
The FDC3 API can be made available to an application through a number of different methods. *In the case of web applications*, a Desktop Agent MUST provide the FDC3 API via a global accessible as window.fdc3.
API Access in 1.2 <https://fdc3.finos.org/docs/1.2/api/spec#api-access>
The FDC3 API can be made available to an application through a number of different methods. *In the case of web applications*, a Desktop Agent SHOULD provide the FDC3 API via a global accessible as *window.fdc3*.
This is expanded on in the supported platforms section in both versions,
e.g. in 1.2 <https://fdc3.finos.org/docs/1.2/supported-platforms#native>:
The FDC3 standard does not define wire formats for communication. Hence, for native applications to be FDC3-enabled, they need to make use of a library (e.g. a DLL in .Net or JAR file in Java) that provides them with an implementation of the FDC3 API. FDC3-enabled native applications are therefore specific to particular desktop container frameworks (or other suitable environments) that provide the necessary libraries.
Despite this limitation, implementing support for FDC3 in a native application can allow it to interact with a wide variety of FDC3-enabled web applications.
I.e. the Standard's documentation acknowledges that the lack of a standardized approach to getting an API reference in other languages is a significant limitation, linking the value that can still be provided without one to interop with web (in this case container apps built with web technologies) where there is an answer. We also lack interface definitions in other languages - although I'm aware of at least a couple of community members working on that problem.
Again, it's rather obvious that the lack of standardisation is what's limiting native implementations and making it difficult to test them for conformance. The assertion that it is the requirements placed on web (which enable its conformance testing) that limit native, is daft.
K
P.S. I'm back in the office tomorrow and will work on arranging the proposed meeting to further the discussion.
|
|
Just on the issue of the provision of the
Of course, there may be some valid counter-arguments to the ones I made above which could make a compelling case for the removal of the global from the standard (and which actually outweigh the disruption caused by the removal). I'd be interested to hear of any. The main one I can think of off the top of my head is if there was a requirement to install more than one DA in a given environment (although I believe this would go beyond what the current FDC3 spec provides for, and I would also have thought that any potential need to do that would likely be significantly undercut by the availability of a Desktop Agent bridge a.k.a. Backplane solution for interop between apps running in different ecosystems / containers that used different DAs). For reference, the full 'FDC3 Desktop Agents vs. API implementations and using FDC3 on the Web' discussion thread I was referring to is here: |
|
Great summary @novavi |
|
At the last FDC3 Standards Working Group meeting (#899) it was resolved that a discussion group should be set up to discuss what changes need to be made to how the FDC3 API is accessed, to enable its use in a Web browser (rather than a container or browser extension that makes the API available at This is currently only possible through the import of an implementation from a proprietary module (allowed, but not recommended in standard version <=1.2, but not in 2.0), which has significant downsides for the FDC3 ecosystem as it requires an application to be adapted for each desktop agent that it may be used with (which is not the case when working with an injected To help us organise the discussion group at a time suitable for all those who wish to participate, please indicate your interest and dates you could attend below (by clicking on the relevant emojis):
Poll Closed: result: |
|
Kris mentioned in the 'FDC3 for Web Browsers Discussion group' meeting today (#908) that people could raise here discussion points about the use of FDC3 in web browsers and/or points for the next meeting relating to any potential evolution of the standard. I don't actually have any specific issues for the next meeting at this stage (I'm sure I'll think of something nearer to the time). But just to pick up on one point raised today about the alleged inability to use the postMessage API for native browser local cross-origin comms (sorry, I can't remember who mentioned it now). To be clear, postMessage API can in fact be used successfully for native browser local cross-origin cross-window interop. The restriction in this case is that (unlike the same-origin-only Broadcast Channel API) postMessage API requires a target window reference and also (assuming you sensibly want to avoid reliance on asterisk wildcards for security purposes) a target window origin when posting messages. In the case of an iframe, it can perform limited discovery of sibling iframes because even though it can't access its container's DOM on a cross-origin basis, it can still use the container's This all means that postMessage API can be used for cross-origin cross-window local interop, but that you simply need a solution to the above routing problem. One solution is to use some sort of lightweight 'hub' or 'router' in the original container window to help orchestrate things for the DAs in the app windows (e.g. route interop/channel messages, and open external windows on behalf of the iframe apps and track the references to those opened windows). One consequence of this approach (which is broadly what I used in a limited FDC3 DA implementation myself) is that it matters where a window is opened from. For example, if you opened an external window via the original container (i.e. an In practice, I don't believe the extra hop via a 'hub' or 'router' in the container presents any problems for most real-world scenarios. Now, there might be some limited alternative solutions for peer-to-peer style iframe interop, perhaps involving some sort of handshaking to overcome the initial lack of visibility around the window hrefs (although I'm honestly not sure how you'd do this securely in a manner that would allow you to ever trust the other iframe window). The issue of peer-to-peer local interop with external windows seems intractable to me though - at least based on current browser APIs that I'm aware of . I'd actually be interested if anyone had any different patterns for cross-origin local messaging in general. Anyway, the end result of all this is that for most real-world scenarios you could potentially use postMessage API for native browser local cross-origin interop - as long as you use a sensible approach for message routing. However, in the specific theoretical situation where FDC3 apps / windows were opened completely independently of each other (a so-called containerless scenario) you would then have to use a cloud-messaging WebSocket API approach, instead of being able to use a local-messaging postMessage API approach. And of course there are a few other scenarios where a cloud-based approach could achieve things that a local-based approach could not support e.g. direct interop with an app on a another device, without using a bridge. |
|
thanks @novavi - this an excellent summary of what is feasible as well as the challenges with the client only approach to interop in the browser. The reproducibility of a URL and the controls around cross-origin trust are fundamental building blocks of the web and not wanting to break these patterns lead us (at Connectifi) to the cloud approach. My thoughts post the meeting are pretty brief:
Looking forward to hearing from the rest of the community on this. |
|
thanks @nkolba - you raise a valid point about the reproducibility of a URL. It's certainly true that if a window with a given url behaved differently depending on where it was opened, this could cause confusion to end users. And I agree that a cloud-based approach certainly has the potential to eliminate that particular (undesirable) difference. Having said that - playing devil's advocate for a moment - one could argue that although ensuring reproducibility of a URL would be a good thing to aim for, it's possible that the cost might be paid in greater friction in non-federated identity scenarios, if a cloud-based approach ended up forcing an (undesirable) additional logon for the agent in the given app. This is something the user wouldn't see when opening the same app in either a desktop container or in a MFE container that used local interop. So it's possible that there could be trade-offs, depending on the specific setup of the institution and the ISVs involved. Of course, every setup is different - which is why I think a good result for the community would be to have a standard which encompassed all the common scenarios, and a range of solutions from agent providers to cater for those different scenarios. I have to say that - based on my current knowledge of the FDC3 standard at least - I don't really agree with the assertion that removing the Now that I think about it, I've yet to actually see a convincing upside for any proposed removal of Firstly, I don't particularly buy into the argument that static import declarations are necessarily better in every circumstance just because they are the more modern ES way. To me, a DA feels like a different category of import than something like a UI component (where an import declaration would always definitely be better) in that it's an API that can be injected into the environment in the case of a desktop container. For me, this makes it more analogous to a polyfill for a new browser API which hasn't yet been made available in all browsers. Additionally, it's not clear to me that a static import declaration is a good method for loading an agent in any case (since import declarations can't be used in conditional blocks, this would imply either fixing to a single specific agent at build-time or alternatively including multiple agents in the resulting script bundle even though only one was required at runtime). That's actually what caused me to look at the idea of an installer library in the first place. Secondly, I think I'd probably need some convincing that there's any significant downside to having the agent installed in a global (instead of inside part of the main app module) from a security perspective. In particular, having the agent hidden in the revealing module pattern or similar doesn't seem to offer any meaningful protection from being tampered with by malicious code. For example, if someone wanted to write malicious code to use as part of a XSS attack to read all inbound and outbound interop messages, it would actually be far easier to directly target the native browser APIs that the FDC3 DA relied upon (postMessage or WebSocket, to attack local or cloud interop approaches respectively) than to target the layer on top i.e. the multiple intent/channel methods of the FDC3 DA itself. However, I can believe there could be some genuine upsides which I'm not fully aware of - so I'm definitely interested in hearing any other arguments on the matter. As for the question of open source vs FDC3 standard in terms of the strategy for an installer library or similar, my main concern with an open source approach would be the risk of untested/unmaintained implementations and unnecessary duplication/fragmentation. To this I would also add the possibility of confusion in the case of smaller ISVs where the developer knowledge of FDC3 may not initially extend much further than their boss having mandated some work with a deadline and a simplistic "Get FDC3 done" slogan. More specifically, if you think about the combination of multiple open source agent installer implementations with (over time) different versions of the FDC3 spec and (as the market grows larger) multiple competing desktop containers and web-based agent providers, it could easily lead to smaller ISVs building apps that don't do a good job of installing an FDC3 DA. At best, this might mean the app not working reliably or consistently across different containers. At worst, this might risk an approach containing security flaws that would not be limited to that particular app i.e. which could potentially compromise the interop of the whole ecosystem / MFE container that the app was loaded into (even when all the other apps in the ecosystem had done the right thing). This is why I would argue in favour of having some form of installer library or equivalent mechanism as part of the FDC3 standard itself - where it can be agreed, designed, implemented, tested and maintained in a manner that promotes confidence in FDC3 as an open interop standard and enables growth in FDC3 adoption amongst ISVs and institutions. I appreciate that others might take a different view on this, so I'd also be interested to hear from the rest of the community. |
|
Hi,
- the *window.fdc3* requirement is the only clearly identified issue
with the spec relating to FDC3 in browser
Like @novavi, I heard no clearly articulated advantage to this proposal, nor much support for it at the meeting. We did however hear from a number of speakers with concerns about such a proposal, particularly with no clearly defined successor to the global. Many of us want to avoid creating a situation where:
- App developers have to target particular vendor implementations or deal with excess complexity when needing to acquire an API handle (making it harder to get started),
- Apps can only interoperate with other applications that included the same library at development time (making the ecosystem factional).
- These challenges impede the uptake & growth of FDC3.
As such, I continue to believe that it is in fact the inclusion and bootstrapping of proprietary libraries, without a standardized pattern or open/cross-vendor library support, that is the greatest issue facing FDC3 on the web. This is particularly the case as it will take away the ability for an app to be (Desktop Agent) vendor agnostic if it wishes to be (highlighted as an important property of FDC3 at the meeting multiple times).
Other interesting points that we heard at the meeting:
- There are multiple approaches to FDC3 on the web, including apps launched (windows opened) within the scope of a Desktop Agent (iframes and windows opened with window.open) and those launched independently have different needs/approaches that might apply.
- These should be carefully considered as the client-side communication that FDC3 generally provides, is harder to implement in the independent launch scenario and there is a fair chance that when (up to) any 3 financial services firms are engaged in communication (e.g 2 app vendors and user) at least one may not be keen on communication passing through the servers of a 4th firm.
- Applications might want to work with different Desktop Agents, but could talk to each other through Desktop Agent Bridging.
- It might make sense to further sub-divide the Standard into:
- API interface and methods of retrieving access to it.
- Desktop Agents and Browser Agents with different requirements (at the least scoping for 'web' may need dividing into Web containers and Web browsers).
Hence, the overly simplistic proposal of dropping the requirement for the fdc3 global is a distraction from the real issues we need to work on. A solution to those may see the global superseded - but its existence does not block the use of FDC3 on the web.
|
|
Note that the client-side integration with an IFRAME requires the ability
of the application to communicate its content height to the parent window
which hosts the IFRAME, so the protocol for this should be added to the
FDC3 spec, too.
A good point (as most solutions to that I've seen use postMessage between the parent window and the iframe). However, not every layout will require that (iframes might internally scroll, or you might use full windows via window.open only). Nevertheless, it seems worth considering a solution.
Both patterns must continue to work if there is an injected window.fdc3,
therefore a fail-fast algorithm for determining whether to wait for the
fdc3Ready event should be added to the FDC3 spec. One possibility is to
inject window.fdc3 = null as soon as this becomes possible during page
loading and then replace it with the full implementation before firing
fdc3Ready, or removing it before firing fdc3Ready or another event if the
agent decides not to trust the application web page after additional
security checks.
Also a good point. This advice on API Access in the Standard will almost certainly need adjusting to facilitate testing for the (impending) availability of an implementation:
The global window.fdc3 must only be available after the API is ready to use.
|
|
FWIW I don't we're that far apart in what we're saying and I think we all agree that producing a common library is the best way forward. Perhaps the best course is to put the larger questions on the standard to the side for now and focus on that. |
|
Thanks Nick. That seems like a reasonable focus for the next meeting's agenda, see you there.
|
|
I assume we're talking about a common installer library here? If so, this sounds positive. I think to move forward it would be worth first defining clearly what should be in and out of scope for the initial focus on an installer library. Based on the discussion so far, there are many wider issues raised by the use of FDC3 in a browser-based environment which can probably be kept in mind but largely parked for discussion purposes (this includes the idea of running different agents in different apps, which was floated in the last meeting). So the idea of sub-dividing the standard as @kriswest suggested to allow an initial focus on API interface and methods of retrieving access to it seems sensible to me. Clearly everyone will have their own views - and I'll be very interested to hear everyone else's - but in the meantime some of the things that spring to mind when I think about a common installer library now include:
I could go on further, but will just put the above thoughts forward for now. Look forward to discussing more in the next meeting. |
|
For the record, I should correct something that I mentioned in one of my recent posts about browser-based local interop above (#896 (comment)) where I stated that postMessage API requires a target window reference - and that this always imposes limitations around app launching and requires a common 'hub' or 'router' window for messaging. I had originally ruled out Broadcast Channel API completely on the basis of the same-origin policy restriction it imposes. And since postMessage API is (as far as I am aware) the only native browser local messaging API that works for the cross-origin scenario (which is necessary in most real-world situations) I had thought that one would just have to live with the requirement for window references. In practice, that would mean apps delegating interop and window opening functionality to a 'hub' or 'router' running at the micro-frontend container level. Moreover, it would mean that if a user launched an app independently (i.e. in manually opening a separate window or tab, and navigating to the app's url) then that app could not participate in local interop. However, with a bit of lateral thinking, I can now see that there is a fairly simple mechanism to overcome the above problem. This mechanism effectively provides for cross-origin interop between isolated independently-launched windows. The solution I came up with uses postMessage API in conjunction with Broadcast Channel API, and it works along the following lines:
This goes further than I previously thought was possible with browser-based local interop. To be clear, based on a spike I just created, the above solution appears to work - but I have to confess I haven't (yet) tried it in anything beyond that limited spike. Of course it's worth noting that for a local browser-based app to interop with a local desktop container or a remote (e.g. Citrix-based) container, then cloud-based interop is still absolutely necessary. |
@novavi This is a case a Desktop Agent Bridge could/would solve for (as a browser page could connect to local websocket). |
|
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. |
|
The discussion group's working doc was migrated to Sharepoint from Google drive and can now be found here. |
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.
The text was updated successfully, but these errors were encountered: