FDC3 Desktop Agents vs. API implementations and using FDC3 on the Web
Kris West
There have been a few discussions amongst the maintainers and firms implementing Desktop Agents and/or the FDC3 API over the last few weeks, prompted by the FDC3 Conformance framework and program. These discussions related to what is being tested by the project and hence what certification means - and have a bearing on the future direction of FDC3 and particularly how we might go about making FDC3 available in a web browser without an extension. As an FDC3 maintainer, I'd like to state a position on this discussion and provide some references:
First off, it's been suggested that we are just testing the implementation of the Desktop Agent API. However, the 'API' qualifier does not appear in the any of:
- the full name of the program ("Certified FDC3 Desktop Agent Conformance Program"),
- it's readme file: https://github.com/finos/FDC3-conformance-framework/blob/main/README.md, or
- the Terms & Conditions that define the program: https://github.com/finos/FDC3-conformance-framework/blob/main/terms-conditions/FDC3-Certified-Terms.md
Further, the program's T&Cs state:
Additionally, the following specific rules also apply to use of the Certified FDC3 Marks and Participant FDC3 Combinations:
...
Do not state or imply that there are different degrees of certification or conformance. For example, do not say that a Qualifying Offering is "more certified" than another, or that it was "certified before" another Participant. However, this does not prohibit use of Certified FDC3 Marks designated for Profiles that a Qualifying Offering has passed, as described above.
I.e. an offering is conformant or it is not. There are currently no sub-units of conformance.
There are some subtle, but very important, differences between the Desktop Agent API and a Desktop Agent. In particular, (for apps based on Web technologies) it is the job of the Desktop Agent to make an implementation of the API available to applications, at a consistent location (window.fdc3), as stated under 'Supported Platforms' in the Standard's docs.
For a web application to be FDC3-enabled, it needs to run in the context of an environment or Platform Provider that makes the FDC3 API available to the application. This environment could be a browser extension, a web or native app, or fully-fledged desktop container framework.
and
Adherence to the specific binding is required for web application platforms.
Further, this is also the very first requirement under the Desktop Agent API's own compliance requirements:
An FDC3 Standard compliant Desktop Agent implementation MUST:
- Provide the FDC3 API to web applications via a global accessible as `window.fdc3`.
This allows web app developers to write code once that will run in any compliant Desktop Agent, making API calls that we are all familar with like `fdc3.raiseIntent(...)`, `fdc3.broadcast(...)` etc. (n.b. properties added to `window` are in the global scope for the window's DOM and so it is generally omitted - hence `fdc3.broadacst` is equivalent to `window.fdc3.broadcast).
It is important to the developing FDC3 ecosystem that we keep this consistent so that app developers only need to target one style of implementation, only need to test in one desktop agent rather than many etc. and ultimately so that more conformant FDC3 app implementations are made available to all adopters. Which (as you've no doubt heard before) is all in aid of:
advanc(ing) the ability of desktop applications in financial workflows to interoperate in a plug-and-play fashion, without prior bi-lateral agreements.
The vendors that have recently submitted Desktop Agent API implementations for testing that run on the web and are imported into applications as NPM modules specifically do not meet these requirements. If the API is provided as a reference other than `window.fdc3` then code written with an imported module and a custom reference to the API won't work in other agents and vice-versa. Further, even if the imported module does create the `window.fdc3` reference then the app is still not running in the "context of an environment or Platform Provider that makes the FDC3 API available to the application" and is likely to have conflicts with Desktop Agents that do provide the reference. Of course, code might be written to try and account for such situations - but then we're back to testing against every Desktop Agent and probably some vendor lock-in that FDC3 specifically tries to avoid.
To be compliant, those implementations would have to be run in a container or within the context of a browser extension that provides their API implementation in the expected place. At least one of the currently badged implementations ships with such an extension and you'll see on its badge that it is conformant ONLY in that configuration.
FINOS/LF also state in the program's T&Cs that:
The Linux Foundation has established the Conformance Program to achieve two objectives: 1) The Linux Foundation needs to ensure that the Certified FDC3 Marks and the FDC3 Word Mark remain reliable indicators of the qualities that they have been created to preserve, and 2) The Linux Foundation needs to ensure that community members are able to accurately describe their Qualifying Offerings.
The last sentence is particular relevant to this discussion as we are discussing submissions that fall (just) on the wrong side of the line regarding compliance/conformance. They are not far off - but the difference is really important (in my opinion) for the reasons described above.
However, 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).
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.
Hence, please do get in touch if you want to get involved in this work or otherwise have something to contribute to the discussion.
K
Rob Moffat
nicholas kolba
Hi Kris,
I hear the concerns, but have a different point of view on this topic - which is a big one and one that we’ll need the community to weigh in on. But some brief points in the meantime:
FDC3 is about app interoperability, not about app fungibility between containers. I.e. the standard requires the FDC3 API to be consistent across implementations, not for all app code to be the same.
All desktop containers contain extensive proprietary APIs and any app going cross-container (or between browser and container) today writes adapter code to bridge the differences in APIs and behaviors.
All FDC3 API code injected into any app today is proprietary to that container.
Allowing applications to use a more standard way to implement FDC3 in their app (injecting a global which may or not be there is not standard) actually reduces the proprietary nature of the implementation, and provides application owners with more choice and control.
Enabling application owners to choose how they connect to FDC3 interop is not counter to the principles of FDC3 and in fact addresses key inhibitors for adoption around security.
Agree that there is language that has been added to 2.0 (a global was a ‘SHOULD’ in 1.2 - with module implementations of the API as a ‘MAY’ - and in the conformance test description that is very specific to the API being injected by a desktop container. However, this is our language and if the community wants to change these definitions to open the FDC3 standard to new ways of implementing interop then there is nothing stopping us from doing so.
Finally, I’d add that in general, we should have a high bar for making something a requirement. Otherwise, we are limiting the reach and adoptability of FDC3.
Looking forward to discussing more.
-Nick
--
To unsubscribe from this group and stop receiving emails from it, send an email to fdc3+uns...@finos.org.
nicholas kolba
Let’s leave aside that WORA was the tagline for Java and that web development has always involved apps performing some level of adaptation to different environments (browsers, OS, media, etc). We should be perfectly clear, what is really being discussed here is not the FDC3 API itself, but the mechanism by which an app gets a reference to the FDC3 API. The difference in mechanism being discussed is between having the reference injected as a global - something decidedly not standard - and it being imported by the app as a module - something entirely standard and normal practice (and what is characterized as ‘proprietary’).
This comes down to mechanism because every FDC3 API from any FDC3 provider is implementation-specific javascript (conforming to a standard interface) that is running in a browser and calling back to some other process executing FDC3 business logic. To describe the “HTML5 API” module is an ironic analogy because in fact, this is done all the time on the web and called “polyfill”. So if FDC3 someday did get picked up by the W3C (web intents 2.0?) we could drop the polyfill API and just work directly in the browser. Until that time, we are in polyfill land.
Now, let me make a confession. As the person who introduced the fdc3 global as part of the standard, I’m here to say now that I was wrong. The mechanism of injecting a global, while a typical practice in Electron, goes against web standards and best practices. It limits implementation choices for application owners/developers while doing nothing to improve interoperability.
In all fairness, the FDC3 1.x spec categorizes the use of the global pattern as a ‘SHOULD’ and does explicitly call out other patterns as something that a provider ‘MAY’ do. But it was a mistake to give it so much weight in the first place. What matters for interoperability is that the FDC3 API itself is consistent.
Finally, you raise concerns of the risk that developers can end up in a world where they must develop for each platform, test for each platform, and pay royalties to each platform. Let me address these points:
Developing: In the case being discussed, FDC3 APIs are certified to be the same. This also seems to be ignoring the fact that desktop containers have radically different APIs for all sorts of other proprietary things like window management, notifications, and inter-application messaging outside of FDC3.
Testing: as above. We have FDC3 conformance testing to ensure that this isn’t an issue.
Royalties: this seems to be inferring something about business models. Of course, if all platforms are rent seeking, then this would be a problem. But I can assure you, this is not the case with every provider of FDC3.
I completely agree with the sentiment of empowering application owners. What could be more empowering than maximizing their implementation choices while using standards to ensure interoperability through FDC3?
"Write once, run anywhere" has been a key factor in the success of FDC3. Perhaps, the key factor because, without this assurance, application providers are thrown back into a world where they must (1) test on every platform, (2) modify their code to run on every platform, and (3) potentially pay royalties to every platform. Interoperability can only thrive if the standard protects applications from this burden.Consider if browsers had gone down the opposite path, for instance, the HTML5 API being available on Edge only if your web page imported Microsoft's HTML5 library, or on Chrome only by importing a library from Google, and Firefox, Opera, Brave, etc, etc.To date, "write once, run anywhere" has been made possible via preloads, which are admittedly only available through Electron and browser extensions.. That said, it should be possible to offer "write once, run anywhere" for web-based desktop agents. That path should be fully vetted before we consider lowering the bar.This is not to say that proprietary methods can't or shouldn't be offered by enterprising vendors. There may be implementations where "write once, run anywhere" isn't an expectation or requirement (in much the same way as Chrome's browser extension API has been very successful despite it being proprietary.) It simply needs to be clear to application owners that operating in this sphere potentially subjects them to any or all of the (1), (2), or (3) conditions outlined above. The current standard provides a very clear indication to applications that they are taking on these risks.
Kris West
The difference in mechanism being discussed is between having the reference injected as a global - something decidedly not standard - and it being imported by the app as a module - something entirely standard and normal practice (and what is characterized as ‘proprietary’).
This is playing with semantics a little - it's a proprietary module being imported that is the problem - not the act of importing a module. In fact, importing a non-proprietary FDC3 module was proposed as part of a solution to the problem in the original post.
To describe the “HTML5 API” module is an ironic analogy because in fact, this is done all the time on the web and called “polyfill”.
It's not ironic at all - HTML5/the living HTML standard exists as different vendors got together to both move things forward and eliminate the variation that made it so hard to write applications that worked cross-browser. An effort that's been pretty successful as you tend to find yourself using a lot less (if any) polyfills to achieve fairly standard behaviour these days (ending a decade of suffering for app developers in the process). Further, polyfills implement or mimic the standards so that code written to the standard will run in different places without modification. Yes, we're likely to need a polyfill to make things work in a browser in a standard fashion (unless or until browsers adopt something) - but that is a very different prospect than using a proprietary module and having to change that for each platform you need to work with.
Until that time, we are in polyfill land.
Now, let me make a confession. As the person who introduced the fdc3 global as part of the standard, I’m here to say now that I was wrong. The mechanism of injecting a global, while a typical practice in Electron, goes against web standards and best practices. It limits implementation choices for application owners/developers while doing nothing to improve interoperability.
What matters for interoperability is that the FDC3 API itself is consistent.
Developing: In the case being discussed, FDC3 APIs are certified to be the same.
This also seems to be ignoring the fact that desktop containers have radically different APIs for all sorts of other proprietary things like window management, notifications, and inter-application messaging outside of FDC3.
You, I and the other maintainers have been involved in many conversations about FDC3 choosing to specifically limit its scope to what's needed for app interoperability - and FDC3 has been successful in providing advantages (apps that are interoperable with each other AND portable between containers) without having to take on these areas. Those that use the proprietary APIs of containers are not portable (but perhaps they don't need to be if they're just supporting UX in a specific container). The fact they offer other unstandardized APIs clearly doesn't negate the benefit of providing standardized ones for apps that need/want to be portable (a sizeable part of, if not the entirety of, the vendor community).
Testing: as above. We have FDC3 conformance testing to ensure that this isn’t an issue.
Royalties: this seems to be inferring something about business models. Of course, if all platforms are rent seeking, then this would be a problem. But I can assure you, this is not the case with every provider of FDC3.
It does open the ecosystem to abuse of market position if you have to test against particular vendors that developer's charge for access - which you do if you access the API differently. However, I agree that this is not the case with most vendors who offer developer licenses or similar that allow app vendors unpaid access for evaluation and testing. That said, it is still creating work and uncertainty for app vendors (on each platform) that would otherwise be avoided.
I completely agree with the sentiment of empowering application owners. What could be more empowering than maximizing their implementation choices while using standards to ensure interoperability through FDC3?
I really don't see the additional benefit that what you propose offers or how it is empowering anyone... By reducing the level of standardisation we're creating more problems to solve (are those the implementation choices?) but not creating any capabilities. An app importing a proprietary library becomes more limited on where it can be used and who it will interoperate with, not less.
In my opinion, we should be looking to solve this problem and create a genuinely standard solution for FDC3 on the web (with a universal polyfill?). This should allow single app implementations to run on the web OR under containers/browser extensions, supported by platform implementations from various interchangeable vendors, without requiring code customisation. The alternative is to back peddle, give up the hard-won advantages of app portability and massively reduced app integration/testing cycles and probably slow or stall the adoption of FDC3 that's been going so well.
I.e. I'm keen to collaborate on how to solve the issue rather than just lowering the bar so we can pretend it's not there...
K
Riko Eksteen
--
You received this message because you are subscribed to the Google Groups "Enrolled participants in the FDC3 standard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fdc3-participa...@finos.org.
To view this discussion on the web visit https://groups.google.com/a/finos.org/d/msgid/fdc3-participants/CAGhJpMwhYHukhak1VAoxNfx8f1TZTUxGOkZd6XBsq1kKikib%2Bw%40mail.gmail.com.
This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Adaptive Financial Consulting Ltd.
If you are not the intended recipient of this email, you must neither take any action based upon its contents, not copy nor show it to anyone.
Please contact the sender if you believe you have received this email in error.
Adaptive Financial Consulting Ltd is a company registered in England and Wales. Registered number: 08105955. Registered office: 70 St. Mary Axe, Level 13, London, EC3A 8BE, United Kingdom.
nicholas kolba
- preloads are script includes, they are not equivalent to native browser APIs
- every fdc3 API implementation - by necessity is proprietary (or in the case of open source ones - specific to that implementation)
- what matters is that the API interface is standard and consistent - which we have mechanisms for: the FINOS types and conformance testing
Colin Eberhardt (He/Him)
Sent: 20 January 2023 15:22
To: Riko Eksteen <ri...@weareadaptive.com>
Cc: Kris West <kr...@finsemble.com>; Terry Thorsen <terrence...@gmail.com>; Enrolled participants in the FDC3 standard <fdc3-par...@finos.org>; fd...@finos.org <fd...@finos.org>; rob.m...@finos.org <rob.m...@finos.org>
Subject: Re: [FDC3 Participants] Re: FDC3 Desktop Agents vs. API implementations and using FDC3 on the Web
Kris West
The fact that it is also framework/language specific is an additional problem. Would we say a .NET version is not able to obtain a conformance badge because it does not have a window.fdc3 entry point?! The only way to do it in such a framework would be via importing, again illustrating that imports are not less open or standardised than global objects.
The requirement is qualified as applying only to web applications in both the Desktop Agent API specs and Support Platforms page. The current standard docs acknowledge this as a limitation for native implementations:
The FDC3 standard does not define wire formats for communication, nor does it define language specific API bindings, other than JavaScript and TypeScript. Hence, for a native application to be FDC3-enabled, it needs to make use of a shared library (such as a .NET DLL or JAR file) that provides it with an implementation of the FDC3 API. Therefore, an FDC3-enabled native application is currently specific to a particular desktop container framework (or other suitable environment) that provides the necessary library.
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.https://fdc3.finos.org/docs/supported-platforms#native
...from an objective perspective, in the FDC3 1.2 specification, window.fdc3 support was always opt-in (a "SHOULD"), and therefore we cannot and must not make it a requirement for the conformance badge for this version.
The API introduction begins with:
Key Elements:...
window.fdc3global object andfdc3Readyevent, for accessing FDC3 operations globally
Usage
There are two main ways FDC3 can be used from web applications:
1. Direct Usage
Simply rely on the global object being made available by your desktop agent, and address the API directly:...
2. NPM Wrapper
The@finos/fdc3npm package provides a wrapper around FDC3, allowing you to use it with ES6 import syntax:
and in the Desktop Agent API reference:
It is expected that theDesktopAgentinterface is made availabe via thewindow.fdc3global object, and that thefdc3Readyevent fires when it is ready to be used.
The global then appears in every desktop agent API example through the docs (save those working with Channel objects retrieved via it).
We may have to have a different conversation around it for FDC3 2.0, as I believe the wording around window.fdc3 has changed for this version (which either I didn't know about, or I forgot about!). I would personally like to see window.fdc3 be deprecated (slowly) in favour of more modern modules and imports that are agnostic of the specifics of web technologies, but this is a discussion for the community to be had for future versions.
I raised the issue that made the change (which had been proposed away back when the fdc3ready event was created), it wen through the Channels, Feeds & Transactions group before making it to the SWG - it looks like you merged the PR for it after a vote in the SWG on it.
I certainly don't have a problem with replacing window.fdc3 (with backwards compatibility!) in future version, particularly if we can enable use of the standard in more places - but think it really important that we do so in a way that allows applications to remain vendor-agnostic. If we waver on that point we lose a lot of the benefits of standardization.
K
Kris West
- every fdc3 API implementation - by necessity is proprietary (or in the case of open source ones - specific to that implementation)
- what matters is that the API interface is standard and consistent - which we have mechanisms for: the FINOS types and conformance testing
Terry Thorsen
Terry Thorsen
Leslie Spiro
My take on this is to start by asking; who are the users of FDC3 and how can we help them?
By we, I mean people working on FDC3 not just those of us who have commercial products that offer FDC3 implementations .
My view is that the aim of FDC3 is to help developers offer Interop in their products, so that they can integrate with other apps they write and with other applications without prior agreement.
For companies that have chosen a Platform (typically a container), to run their applications, I don’t think there are any real issues about initialisation even if it is Platform specific. In this context FDC3 offer an API (for some Platforms the only API) to carry out Interop, and it also offers (and I think this is increasingly important) a set of well defined contexts to describe key items in our domains e.g. clients, instruments, trades etc. But in this situation the in-house developers don’t get that much benefit from FDC3 over using proprietary interop API’s.
My view is that the biggest beneficiaries of FDC3 are the Software Vendors (ISV’s) for whom FDC3 is about a Container agnostic API and data context for Interop that they can use in their applications, to enable Interop functions when they are running in an environment (not necessarily a container) that offers FDC3. These 3rd party applications then increase the value of FDC3 (over container specific API’s) to Enterprise developers because they extend the set of applications that their in-house applications can Interop with.
In this light we have to ask how is it helping ISVs (who want as wide an audience as possible for their software) if we only allow a Platform to call itself FDC3 Compliant if it offers code injection. Surely any ISV (and by extension anyone aiming to work together with that software) would rather have the option of using FDC3, albeit with some platform specific initialisation logic, than having to use some other API’s. Terry spoke about the inconvenience of having to write container specific initialisations, which is true, but it seems the alternative is much worse. ISV’s would either need to re-write all their Interop code to use Platform specific API’s, or rely on the vendor announcing they support FDC3 without the vendor having to run the Conformance tests to prove it.
We need to accept that allowing Platforms to offer FDC3, even if it requires initialisation logic, is more helpful to our community than excluding such Platforms.
Our recommendation would be to allow Platforms like Glue42 Core+ to assert that they are ‘FDC3 Compliant (requires custom load)’ to indicate that they do not inject libraries.
Leslie
From: fd...@finos.org <fd...@finos.org>
On Behalf Of Terry Thorsen
Sent: 20 January 2023 16:05
To: Enrolled participants in the FDC3 standard <fdc3-par...@finos.org>
Cc: nko...@gmail.com <nko...@gmail.com>; kr...@cosaic.io <kr...@finsemble.com>; Terry Thorsen <terrence...@gmail.com>; Enrolled participants in the FDC3 standard <fdc3-par...@finos.org>; fd...@finos.org <fd...@finos.org>; rob.m...@finos.org
<rob.m...@finos.org>; ri...@weareadaptive.com <ri...@weareadaptive.com>
Subject: Re: [FDC3 Participants] Re: FDC3 Desktop Agents vs. API implementations and using FDC3 on the Web
Let's make sure that we're all on the same page because I think this is being characterized as a philosophical concern (modules=good, globals=bad) when the concern is in fact quite pragmatic. Yes, we're talking about the mechanism. I don't think anyone has a problem allowing FDC3 to be imported as a module per se (as an alternative to a global) if that module is an open source module provided by FINOS. The concern is around FDC3 being imported via _proprietary_ modules, and the implication that in order for an app to run on a given platform, the app developer is forced to add that module to their app - and invent a mechanism to mediate between each desktop agent.
Kris West
Terry spoke about the inconvenience of having to write container specific initialisations, which is true, but it seems the alternative is much worse. ISV’s would either need to re-write all their Interop code to use Platform specific API’s, or rely on the vendor announcing they support FDC3 without the vendor having to run the Conformance tests to prove it.
There is another alternative proposed which is that we collaborate on a standardized way to access a Desktop Agent implementation without either injection or a proprietary module import/initialisation. Otherwise, we are sacrificing that high value to ISVs in favour of approving platforms that don't provide it, and we will encourage the growing FDC3 app ecosystem to become factional and fragmented (which will hurt everyone).
K
nicholas kolba
Kris, Terry,
The objections being raised on the behalf of ISVs seem to be based on an assumption that applications run across desktop containers without any adapter code. In practice, this is not the case as even the conformance tests themselves contain adaptive code. Every ISV code base I’ve seen leveraging desktop containers has had conditional code for different runtime environments, and projects like desktopJS exist solely for this reason. If an application is written to run in both a desktop container and web, it needs to account for the lack of the FDC3 global and create some alternate scheme for interop (or lack thereof). So, while the access to the FDC3 api may be consistent in desktop containers, many other things are not, and this fact undermines any claim of WORA (write once, run anywhere).
WORA is a completely separate issue from app interop. ISVs would be much better served if apps could interop regardless of what container (or even no container) they chose to run in. Regardless, as long as there isn’t a widely adopted standard for ALL desktop container APIs - not just FDC3 - using the WORA argument to not allow different ways of initializing the standard FDC3 API just doesn’t make sense.
With respect to the call to rally around an open source solution “that remains vendor agnostic (preserves the value for ISVs) and allows platforms to adopt whatever they want to”, we already have this with the FDC3 API standard, published types, and conformance testing. If this is not enough, we also have open source implementations such as Glue Core and Sail. The ecosystem is already fragmented along the boundaries between desktop containers and this fragmentation is hindering adoption. Wielding the standard to block legitimate use and innovation will only make the situation worse.
Johan Sandersson
Not trying to get into details on the technical issue – but I do think it's important that we can provide a reasonably standardized way for how an app developer, regardless of language or implementation, can be sure of, and in control of, how and when the FDC3 API is ready for use in their code. The current fdc3Ready was a great addition but clearly more work needs to be done here.
If the window.fdc3 concept is limiting, old-school, or not language agnostic, then let’s not make that a hindrance for more adoption of the standard, or for the certification process if an implementation otherwise is conformant with the API.
Putting my old app developer hat on, I would prefer more environments where my apps could be running, and more discussions around context data, workflows and security controls. In that sense, I would not mind making changes to my apps in order to enable FDC3 in a – for me – new environment if I knew that it would solve real use cases for my clients. The fact that the API is technically available doesn’t guarantee this, and that’s where FDC3 should focus most of its efforts. I would very much like to hear thoughts from other users and real app developers on this subject.
In terms of conformance testing, I think that making it an API test makes more sense, and potentially also makes it more practical to test things other than just web-based Desktop Agents going forward – specifically applications and context/intents. The community will benefit from a more inclusive approach.
Best regards,
Johan
To view this discussion on the web visit https://groups.google.com/a/finos.org/d/msgid/fdc3-participants/CAP0CO3F42fWo_21D7r0drYxZh2HHpM_xCS3UZ_3NPaQYS_ri8A%40mail.gmail.com.
Kris West
The objections being raised on the behalf of ISVs seem to be based on an assumption that applications run across desktop containers without any adapter code. In practice, this is not the case as even the conformance tests themselves contain adaptive code.
The closest I can think of is the occasional wait for a window to close at the end of a test (not FDC3 API use and occasionally necessary as multi-window/multi-renderer Desktop Agents are inherently distributed systems and you need to consider multi-thread race conditions, e.g. between asking the window to close and it getting closed). Thats not really adaptive as most browsers enforce site isolation for security reasons these days so you always have to consider such situations.
Every ISV code base I’ve seen leveraging desktop containers has had conditional code for different runtime environments, and projects like desktopJS exist solely for this reason.
... So, while the access to the FDC3 api may be consistent in desktop containers, many other things are not, and this fact undermines any claim of WORA (write once, run anywhere).
I've seen many apps (and even published a few) that reap the benefits of app interop without any specific container adaption code.
WORA is a completely separate issue from app interop. ISVs would be much better served if apps could interop regardless of what container (or even no container) they chose to run in.
Further, there are ways that FDC3 could enable this technology within both browsers and containers without the need for individual adaption of apps. I know of multiple efforts in this area - in fact one has already been posted on the issue Rob raised for discussion of solutions: https://github.com/finos/FDC3/issues/89
The ecosystem is already fragmented along the boundaries between desktop containers and this fragmentation is hindering adoption.
So let's not extend that to browser-based environments and instead work on eliminating fragmentation by standardizing methods of discovering and initializing API implementations that don't require app vendors to target specific implementations in their code bases! Its eminently achievable and has obvious benefits over the alternative of leaving every app vendor that wishes to offer interop support to solve it for themselves,
Ultimately, this debate is not (no longer?) about whether you should be able to import a proprietary library to get access to FDC3 or whether it should be injected for you (in 1.2 is allowed apparently, 2.0 its not as voted on by the community back in 2021), but rather what we do going forward. For future versions of FDC3 we can enable FDC3 use in a browser without the need to write customisation for each FDC3 implementation or we can require customisation. If a technical solution is possible, it seems to me that the choice is a no-brainer.
Finally, I'd like to echo Johann on this point:
I would very much like to hear thoughts from other users and real app developers on this subject.
P.S. I have to confess that in the earlier part of the debate and discussions on the conformance framework, I didn't realise that 2.0 introduced the compliance requirement change, rather than 1.2. The issue that made the change (#328) was raised in Feb '21 ahead of 1.2 being finalized and had been discussed at meetings before that - it was probably deferred to 2.0 as a breaking change. The requirement was originally introduced by issue #132 which makes for interesting reading, particularly this statement from one of the maintainers:
I think if we let everyone define the access point in a slightly different way, we don’t have a standard anymore, as accessing FDC3 will work differently depending on platform.
I believe its time to expand the ways gaining access - but not in a way that removes the primary benefits of standardisation.
Terry Thorsen
When we say "application vendors", we mean businesses that provide OMS systems, market data, CRM systems, etc. We're talking about the type of 3rd party software that market participants (sell side and buy side), or even enterprises in general, depend upon for their workflows. "Inter" operability is only useful as a standard if it provides a method for two independent organizations (e.g. application vendor and market participant, market participant A and market participant B, or application vendor A and application vendor B) to exchange data without prior bilateral negotiation.
Derek Novavi
I'm late to the party on this thread (and on FDC3 more generally actually) but having recently implemented the fdc3-installer library (https://github.com/novavi/fdc3-installer) that I believe Kris alluded to earlier (and which is referenced on the 'FDC3 For the Web' issue raised by Rob https://github.com/finos/FDC3/issues/896) I will offer my thoughts on this issue anyway.
I'm probably on the other side of the fence than many of the people who've commented so far, in that I work at an ISV (well, actually the software solutions division of an larger organisation). So I have a keen interest in standards being agreed to drive adoption of FDC3, which will in turn allow apps developed by ISVs to interop with each other with minimal friction. I would like to ensure that we can provide FDC3 interop for our customers between (a) different apps within our software solutions suite; and (b) between our apps and third-party apps. It would concern me massively if apps needed to use different mechanisms to import different DAs to expose them to the app code when running in browser-based environments.
When I started considering the use of browser-based FDC3-enabled apps recently, the first thing that struck me was the high risk of DA vendor lock-in - not even so much the impact of lock-in for a single ISV but more that fact that if two different ISVs were locked-in to two different DA vendors then their apps would not be able to directly use FDC3 interop. And yes, a Backplane/cloud-type approach could perhaps theoretically be used to bridge between the two different browser-based DAs, but that seems like using a sledgehammer to crack a nut (surely it's more appropriate to use that as a mechanism only where it's actually required i.e. comms outside the browser to a local native app, a remote Citrix app, or a mobile device... rather than between two different browser windows, one of which might already be using its own, separate cloud-based service).
Clearly, as has already been mentioned on this thread, the use of desktop containers also implies a level of lock-in - but one of the great benefits of FDC3 to an ISV is that at least there is no lock-in at the interop layer.
In terms of this particular debate, my initial observations are:
* Regardless of one's views on making APIs available in the global scope, providing the FDC3 API on the window.fdc3 object makes all DAs consistent in terms of *how* they provide the API.
* Like it or not, moving away from window.fdc3 installation would be a breaking change to the standard and would require existing FDC3-enabled apps to be updated (this applies whether they were calling the window.fdc3.xxx() methods directly or whether they were using the @finos/fdc3 wrapper functions - which internally simply delegate to the window.fdc3.xxx() methods).
* The fdc3Ready() function implementation in @finos/fdc3 - which is published and which ISVs are already using - uses the availability or non-availability of window.fdc3 when deciding whether to resolve or reject (https://github.com/finos/FDC3/blob/master/src/api/Methods.ts).
* It is normal practice for a breaking change to require newer version of the standard in question.
* Though I’m certainly not wedded to, I personally don't have too much of a problem with the FDC3 API being made available in the global namespace. I would tend to draw a distinction between an API that the application *always* imports for itself (e.g. like a grid or a utility library where it is always better to use the more modern module mechanism than to use a global) and an API which may well in a number of circumstances be pre-installed on behalf of the app by the container environment (e.g. in the case where an app optionally runs in a desktop container).
In principle, I'm agnostic about moving away from window.fdc3 installation to a module import as long as this is done in a clear, planned, standardized fashion rather than in an impulsive manner that could lead to a wild west of DAs which all provide their own 'special' mechanisms for making themselves available to an app. If that happened, apps would simply start to implement code-based conditional logic to handle the specifics of an increasing number of different DA implementations, and eventually someone would want to create a standardized library to prevent apps from having to implement the same logic as each other. This doesn't make the problem go away - it simply shifts it from the DA providers (and FINOS FDC3) to the ISVs, which in my opinion would lead to two outcomes:
(a) a suboptimal solution, because ISVs (and I include myself in this) are more likely to be mere consumers of FDC3 DAs, rather than having deep expertise in the provision of FDC3 DAs, or in what trade-offs could/should be made, or what the long-term impact of those trade-offs might be, or what the vision for the evolution of the standard is or should be;
(b) hindering the adoption of FDC3.
It makes little sense to me for ISVs to have to develop/maintain/test conditional DA acquisition logic when this could be done upfront by DA providers working together as part of FINOS FDC3 to ensure that ISVs can benefit from a standardized mechanism for acquiring a reference to the FDC3 API. I can't imagine ISVs would be particularly keen to rely heavily on an unsupported/unverified installer library - so to be clear, my efforts with the fdc3-installer library I put together were aimed more at demonstrating that acquiring a reference to a FDC3 DA is a vendor-agnostic fashion is a solvable problem. For the record, the installer library I put together is more complex than it potentially needs to be in some areas (because of the lack of standardization til now around how browser-based DAs must be provided) but also underdeveloped in a few other areas (I specifically called out in the 'Outstanding Work' section of the recently-updated version of the README the potential issue around trusting an npm package which uses dynamic imports - which definitely requires further thought and investigation).
Ideally, I would like to see a more standardized/streamlined installer as part of a core FINOS FDC3 package offering. I believe this would provide ISVs with more confidence in their decisions to adopt FDC3 because it would make browser-based implementations operate in a similar manner to the way desktop containers do already i.e. individual apps should not have to tie themselves to a specific DA.
One important point that I'm not sure was called out enough in the earlier discussion on this thread (although I might have missed it) is around the dual use of window.fdc3. With my app developer hat on, I initially tended to see window.fdc3 as simply a mechanism for an individual app to obtain a reference to the DA's FDC3 API. But it actually has a second, less obvious, usage as well – as a mechanism for an installer library to determine whether a DA is already provided/pre-installed. In order to implement a reliable vendor-agnostic mechanism for acquiring an DA using a standardized installer (or simply in more limited ISV-developed conditional logic in an app) there needs to be a way to identify whether or not the environment already has a DA installed in it. Put another way, as an app developer or consumer I would want my app to install my chosen browser-based DA (that I have previously selected and arranged the commercials for) when it is run in a browser-based environment, but I would want my app to still be able to use the built-in FDC3 DA if it was running inside OpenFin/Finsemble/Glue42/other (instead of inadvertently overwriting that built-in FDC3 DA API). Now... an installer could attempt to *infer* the presence of an FDC3 DA API by instead sniffing for other, known (but unrelated) APIs that OpenFin/Finsemble/Glue42/other inject into the environment - but to do that would (a) just be relying on *other* globals; and (b) would feel like a dirty hack to me.
As an ISV I might end up favouring one desktop container over another (or I might perhaps favour a browser-based app deployment using a browser-based FDC3 API). But that would only ever likely be as a *primary* delivery model for an application. Even if that was the technology we (as an ISV) recommended our customers use our applications in, many of them might have gone all-in with a different desktop container or web-based platform for their in-house apps and the other vendor apps they rely on. This is why I believe determining whether a DA already exists in the environment is crucial for browser-based DA implementations to *ever* be fully useful for browser-based FDC3-enabled apps.
So in terms of the importance/desirability of window.fdc3 or otherwise, I would start from the point that the goal of an installer library (or perhaps it should be more correctly be called a 'discoverer' library in this context) should be to (a) return a reference to any pre-existing DA where available; and (b) install and return a new DA in the case where one is not already installed.
To me, this implies that if the FDC3 standard did move away from requiring DAs to be installed in window.fdc3 then there would probably need to be an agreed, standardized, new mechanism for desktop containers to provide a reference to their built-in DAs. Now... this could be via an API that they provide (getFdc3Agent() factory function or Fdc3AgentFactory.create() factory class method or whatever) but this leads us to the issue of how that factory function or factory class would exposed and made available to an HTML5 application running in the desktop container, other than (again) via global scope? It couldn't really be exposed via a static module import statement (because the desktop container code is not part of the app's npm dependencies) or via a dynamic import expression (because that would imply an HTTP endpoint). And it would need to be something that had the ability to obtain a reference to the DA's FDC3 API (which doesn't even run directly in the app window) from the desktop container.
It could be argued that it could be considered marginally clearer for desktop containers to provide such a factory function or factory class than simply to blindly preinstall into window.fdc3 without the HTML5 app even asking it do so. But it does seem to me that whatever pattern was preferred, a standardized mechanism would be needed across different desktop container DAs. It’s late as I write this now, and I'd honestly be happy to believe I've missed something here.
One other thought - and playing devil's advocate for a moment - it might even be possible to could consider the prospect of the fdc3Ready() function (or a future replacement of it) evolving to also handle DA discovery i.e. to ensure that a DA was installed and ready, rather than just ensuring that a DA was ready. This might be a bad idea and a step too far (e.g. it would mean the timeout threshold also included the time taken to fetching a DA from a remote endpoint, and a signature change or new function, etc.) and it might be better to keep discovery/installation as a separate mechanism. But I only float this to underscore the fact there is a close relationship between DA discovery / installation, window.fdc3 availability, DA bootstrapping, the 'fdc3Ready' custom event on the window, and the @finos/fdc3 fdc3Ready() function. Therefore any evolution of the FDC3 standard in the area of the provision of DAs might benefit from putting everything on the table and carefully considering the best approach to make the standard work for both browser-based environments and desktop containers going forward, instead of risking an approach that could at best hinder adoption of FDC3, or at worst risk take ISVs down a dead-end.
Finally, just to illustrate the points I was making above about providing a DA to an app in a vendor-agnostic manner I am including a couple of use cases below to highlight the difference between the hardcoded-DA approach and the discovered-DA approach. This is a simplified more generic version of what I just put in the updated README here: https://github.com/novavi/fdc3-installer
It doesn't actually make any difference to the user cases whether window.fdc3 is used for checking for a pre-existing DA / installing a DA... or whether a different mechanism is used. But in the absence of window.fdc3 I believe the prerequisite would be that desktop containers provided some other standard mechanism to expose their DA - which was consistent across desktop containers. Anyway, here's those use cases I was talking about:
Use Case 1: FDC3 App Interop (Using Hardcoded Agents)
Preconditions
* A number of browser-based FDC3 Desktop Agents are available, including:
- Agent A
- Agent B
* Vendor 1 chooses to use Agent A and installs it inside its app.
* Vendor 1 has never dealt with Agent B at all - and has no current plans to do so.
Workflow 1
Company X has an in-house app which also uses Agent A - so they can successfully use FDC3 interop between Vendor App 1 and their in-house app.
Workflow 2
Company Y has an in-house app which instead uses Agent B - and is therefore unable to use FDC3 interop with Vendor App 1.
Use Case 2: FDC3 App Interop (Using Container-Based Discovery)
Preconditions
* A number of browser-based FDC3 Desktop Agents are available, including:
- Agent A
- Agent B
- several others
* Vendor 1 implements its app as follows:
- does not directly install any specific agent
- installs, imports and invokes the installer library
* Company X implements its in-house app as follows:
- installs, imports and invokes the installer library
- adds an installer config file to their browser-based container, configuring it to specify Agent A
* Company Y implements its in-house app as follows:
- installs, imports and invokes the installer library
- adds an installer config file to their browser-based container, configuring it to specify Agent B
Workflow 1
* Company X can successfully use FDC3 interop between Vendor App 1 and their in-house app using Agent A.
* They are also free to switch over to use another agent (or even switch to using a desktop container) if they like, with zero FDC3-related code changes required to either Vendor App 1 or to their in-house app.
Workflow 2
* Company Y can successfully use FDC3 interop between Vendor App 1 and their in-house app using Agent B.
* They are also free to switch over to use another agent (or even switch to using a desktop container) if they like, with zero FDC3-related code changes required to either Vendor App 1 or to their in-house app.
It’s been interesting to hear from everyone else below, and I will definitely be interested to hear further thoughts from others on the window.fdc3 issue and the things that related to it as things move forward.
Thanks,
Derek
From: fd...@finos.org <fd...@finos.org> On Behalf Of
Terry Thorsen
Sent: 22 January 2023 17:06
To: Enrolled participants in the FDC3 standard <fdc3-par...@finos.org>
Cc: nko...@gmail.com <nko...@gmail.com>; Leslie Spiro <lsp...@tick42.com>; Terry Thorsen <terrence...@gmail.com>; Enrolled participants in the FDC3 standard <fdc3-par...@finos.org>; fd...@finos.org <fd...@finos.org>; rob.m...@finos.org <rob.m...@finos.org>;
ri...@weareadaptive.com <ri...@weareadaptive.com>; kr...@cosaic.io <kr...@finsemble.com>
Subject: Re: [FDC3 Participants] Re: FDC3 Desktop Agents vs. API implementations and using FDC3 on the Web
[CAUTION] EXTERNAL EMAIL ..
The information contained in this message is intended only for the recipient, and may be a confidential attorney-client communication or may otherwise be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, please be aware that any dissemination or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify us by replying to the message and deleting it from your computer. S&P Global Inc. reserves the right, subject to applicable local law, to monitor, review and process the content of any electronic message or information sent to or from S&P Global Inc. e-mail addresses without informing the sender or recipient of the message. By sending electronic message or information to S&P Global Inc. e-mail addresses you, as the sender, are consenting to S&P Global Inc. processing any of your personal data therein.
Leslie Spiro
Derek,
Thanks for such a thoughtful and comprehensive analysis. We spend a lot of time thinking about (and talking to) ISV developers and it is really helpful to see this level of analysis from an ISV.
When we deliver apps that are designed to run in both Glue42 Enterprise (a Container DA) and Core+ (a Browser one) we do, as you mention, use the presence of the window.fdc3 and the window.glue globals to make decisions on the environment we are running in and what features to enable.
I am not sure that I see vendor specific loading as a ‘lock-in’ risk, and having some conditional logic which works out which vendor to load would be a small amount of vendor specific code, but most of an ISV’s code will make the same calls whatever DA is being used. And I also think that Nick is right when he says that most (many ? some ?) ISV’s will want to take advantage of other vendor features such as window management, workspace management, notifications and other features and so will often already have vendor specific conditional code or use a wrapper like Desktop.JS to provide vendor agnostic access to common features.
A generic loader capability (like your fdc3-installer) is an interesting approach, but as you note below, one would need to make sure it did not become a vector for malicious code injection. This opens up a load of questions around authentication and trust, that have been raised in our conversations in FDC3 over the years, but not really addressed.
Thanks again, for such a great contribution, I look forward to working with you over the coming years.
Leslie
Derek Novavi
Leslie,
Thanks for your feedback and your thoughts on this more generally.
I completely agree with you and Nick about ISVs generally needing to have some vendor-specific code to take advantage of the features that a desktop contain vendor provides – after all, if they didn’t then there would be far less value in them using and paying for such a container in the first place.
In terms of the ‘lock-in’ risks discussed, I could probably explain my thinking a little further. I think it’s worth calling out three example classes of organization who develop FDC3-enabled apps and/or consume FDC3-enabled apps that can deployed to desktop containers and/or browser-based environments:
* Large ISVs who develop suites of large complex apps which in some cases could be evolved into smaller components running in a desktop- or browser-based container (both to help cross-selling opportunities across their suite of apps, and to enable customer-specific workflows involving other apps which offer business value not supported out-of-the-box with the given suite of apps). These organisations are large enough to (hopefully) have a strategy for a sole (or at least primary) delivery platform, which might involve a vendor-supported desktop container or their own bespoke Electron-based container or a browser-based micro-frontend container.
* Small ISVs who focus on a very narrow and specific market opportunity, and in some cases might have developed only a single app. Such an organization is not large enough (and moreover does not wield enough market power) to specify a particular deliver platform. Indeed, their interests are best served by their app being available to use in any ecosystem across the broadest range of customers. Therefore they have less interest in or ability to leverage functionality which is specific to a single desktop container. The price they pay for this is that integration around windowing, layout management, etc. is expected to be orchestrated by the organisation’s broader ecosystem and container (and it also means that they are less likely to participate in something like centralized notifications). However, they are willing to pay this price because their software is unique and valuable enough to their customers that no-one minds too much if their app has a bit of a different UX and/or might end up floating in a separate window as long as (a) the window can be spawned from the larger organisation’s ecosystem; and (b) the app can interop successfully with the other apps within that ecosystem. Additionally, this small organization might subsequently form a close partnership with one or more larger organisations – it may even be that they have an exit plan to be acquired by one of the larger organisations (which would subsequently offer customers a better, more integrated experience including the aforementioned closer integration with a desktop container).
* Organisations who are customers of the above ISVs. If they are a large organisation, they may have their own desktop strategy. If they are a smaller organization, their choice of platforms may be strongly influenced by their largest or primary ISVs. They want the ability to use the software from different ISVs. They may also have a small number of internal proprietary apps that they use to help run their business. They might want to connect these apps to the large ones provided by the ISVs that they buy software from, using FDC3 interop.
So the ‘lock-in’ risk is not limited to the risk of an ISV locking themselves into a specific desktop container vendor. Because I agree with what you said here that “most of an ISV’s code will make the same calls whatever DA is being used”. The ‘lock-in’ risk extends to the organizations who buy software from ISVs, because it could/would influence their decisions about which ISVs to buy software from if interop is compromised. Specifically, if some ISV apps are limited by the loading of a specific single browser-based DA (or a DA from a limited set of browser-based DAs) then this risks breaking the openness of FDC3. I believe this is a change from the FDC3 situation today, where an ISV can develop software which works across different desktop containers because it has the DA provided to it at runtime (albeit as I mentioned before, accepting the limitations of lacking the ability to use the other non-interop APIs which are specific to each desktop container provider). The new, emerging browser-based FDC3 scenarios clearly change this equation from we’ve been used to up until now with FDC3 DAs being injected in automatically by the desktop container (where apps don’t have to worry about installing a DA). I agree that ISVs could theoretically write/test/maintain their own conditional logic to load an increasing number of different DAs. But it feels like this is less scalable in the absence of standards in this area if/when the number of DAs on the market increases – which is why I had hoped this could ultimately be handled at the FINOS FDC3 level rather than with ISVs reinventing the wheel in their apps.
I agree with your reflection on the risk of malicious code injection, which is another reason why I think this area would benefit from a standardized approach rather than risking each ISV doing things differently (in some cases, possibly using unverified techniques which could expose them to malicious code – in the worst case, at management level, this could wrongly be viewed as a risk around the use of FDC3 generally by that non-technical audience, even though it was actually related to the way the ISV implemented their conditional logic or installer, which could unnecessarily give FDC3 a bad name). With more thought, if it turned out to be impossible to mitigate against the real (or even just perceived) risks around using dynamic import() expressions, there are likely to still be other ways in which a generic installer of some sort could be provided to ISVs. One option would be to move away from the dynamic aspect, and instead ensure that the installer supported a standardized DA package format for inclusion at build-time. An app would then have to install multiple DAs at build time (ideally using lazy-loading at runtime to avoid loading them all in the browser even when only one of them is used in a given user session) but still use the generic installer across their apps. This would come at some cost to the app in terms of its need to think more upfront about DA implementations (as opposed to just the DA API), but one could argue it would still be better for the app to have this standardized approach available to it than if the app (and every other app from every other ISV) had to implement this itself.
In many respects, the debate about window.fdc3 installation obscures this wider issue. Removing the requirement from the spec that DAs must install into window.fdc3 might have the surface-level benefit of looking like a more modern (module import) approach, but it risks being something of a pyrrhic victory if it takes ISVs a step backwards in their ability to discover whether a DA is already installed (for their conditional DA-loading logic, whether that is their own ISV logic, or a standardized FINOS FDC3 installer).
In my opinion, when making such a change to the standard it’s worth being really clear that there is a compelling reason to make the change, and agreement that this outweighs any disruption and/or long-term disbenefit caused by that change. I’m happy to be convinced otherwise, but as I see it at the moment, as long as the FDC3 Standard is geared around have a single DA installed within a given environment (but perhaps this is under discussion?) I’m not completely clear on the tangible benefits of the change to move away from having a well-known location that can be used both to test of the presence of DA (in conditional logic or in an installer) and to use that DA (in app code).
Finally, I would also note that requiring a new way to discover whether a DA is already installed in an environment (in a newer version of the FDC3 standard) is further complicated by the fact that ISV apps would then need to worry about handling both the old (window.fdc3) and the new (as yet unspecified) mechanisms to test for a DA. Moreover, this includes the scenario where the test is needed as part of conditional code to install a browser-based DA. And this would all need to happen before an app even knew which version of the FDC3 spec it was trying to deal with. By definition, the app couldn’t know this until the discovery process had run – so the app couldn’t use the FDC3 version to determine which discovery mechanism to use. The reason that I think this could be necessary is because the app might need to run in existing versions of desktop containers (which support window.fdc3) and newer versions of those same desktop containers (which *might* support a different mechanism) and also have the ability to run in a browser by installing a browser-based DA. This seems like it adds an additional level of complexity which I believe should be borne in mind if making this proposed change regarding window.fdc3. And if the change was indeed going to be made, the complexity around old and new discovery mechanisms would arguably strengthen the case for having a standardized installer to shield ISVs from this complexity and reduce friction when adopting FDC3 (realistically, this complexity quite possibly extends to corner cases that I have not considered above when thinking out load, and that are not easily recognized until this type of thing was actually implemented and tested).
Derek
From: Leslie Spiro <lsp...@tick42.com>
Sent: 26 January 2023 08:54
To: Derek Novavi <Derek....@ihsmarkit.com>; Terry Thorsen <terrence...@gmail.com>; Enrolled participants in the FDC3 standard <fdc3-par...@finos.org>
Cc: nko...@gmail.com <nko...@gmail.com>; Enrolled participants in the FDC3 standard <fdc3-par...@finos.org>; fd...@finos.org <fd...@finos.org>; rob.m...@finos.org <rob.m...@finos.org>; ri...@weareadaptive.com <ri...@weareadaptive.com>; kr...@cosaic.io
<kr...@finsemble.com>
Subject: RE: [FDC3 Participants] Re: FDC3 Desktop Agents vs. API implementations and using FDC3 on the Web
[CAUTION] EXTERNAL EMAIL ..
Kris West
I completely agree with you and Nick about ISVs generally needing to have some vendor-specific code to take advantage of the features that a desktop contain vendor provides – after all, if they didn’t then there would be far less value in them using and paying for such a container in the first place.
In many respects, the debate about window.fdc3 installation obscures this wider issue. Removing the requirement from the spec that DAs must install into window.fdc3 might have the surface-level benefit of looking like a more modern (module import) approach, but it risks being something of a pyrrhic victory if it takes ISVs a step backwards in their ability to discover whether a DA is already installed (for their conditional DA-loading logic, whether that is their own ISV logic, or a standardized FINOS FDC3 installer).
Talk to you all shortly,
kris
https://github.com/finos/FDC3/issues/896#issuecomment-1419000064