In a recent email on the FDC3 mailing list, @kriswest wrote:
... I also want to add that there is clearly significant interest in the community in enabling FDC3 use on the web. There is a strong use case in that it would enable better onboarding journeys with less drop-off (where you use an app on the web with others before adopting a desktop container or similar).
and:
But there are also additional challenges such as how to make the API available reliably without importing a proprietary module from a particular vendor into every app, how to deal with more than one implementation of API/Desktop Agent in the browser at once, how to do this reliably and securely within the browser sandbox etc.. Work needs to be done in the Standard to solve these issues and to make web browser use possible in a future FDC3 Standard version - which I believe is possible (and likely to involve using a vendor-agnostic FDC3 NPM module to detect and connect to API implementation(s)). However, we're going to need to do that work to enable the aforementioned API implementations to be compliant and if we fail to hold the line now on compliance with the current version of the FDC3 Standard, that may never happen.
FINOS meetings involve participation by industry competitors, and it is the intention of FINOS and the Linux Foundation to conduct all of its activities in accordance with applicable antitrust and competition laws. It is therefore extremely important that attendees adhere to meeting agendas, and be aware of, and not participate in, any activities that are prohibited under applicable US state, federal or foreign antitrust and competition laws. Please contact legal@finos.org with any questions.
FINOS project meetings may be recorded for use solely by the FINOS team for administration purposes. In very limited instances, and with explicit approval, recordings may be made more widely available.
A Discussion Group has no direct decision-making power regarding the FDC3 standard - rather it is intended that anything they propose or work on will result in proposals (via Github issues and PRs) for the Standards Working Group participants to consider and vote on for inclusion in the standard.
Participation Requirements
Note: Meeting participants are expected to accept the terms of the FDC3 license (Community Specification License), understand the governance process and have a CLA in place.
Please click the following links at the start of the meeting if you have not done so previously.
Note: Meeting participants are expected to add a comment to this GitHub issue in order that we can track attendance of FDC3 project meetings. Please do this at the start of the meeting.
Agenda
[x] Convene & roll call, review meeting notices (5mins)
[x] Review action items from previous meeting (5mins)
1174
[x] Progress on message schemas and Standard documentation
[x] Revisit how to implement Intent resolver UIs
[x] Revist Channel Selectors UI, including
How to implement a default UI that:
Looks OK by default
Is customizable by the DA
Supports the necessary interactions
Events - including updates to/PR for #1136
[x] Next steps
[x] AOB & Adjourn (5mins)
Minutes
@kriswest provided a recap of the proposal for new joiners to the meeting and then on to the JSON Schema messages being defined to govern the protocol(s) being created.
@robmoffat provided an overview of his POC work on supporting intent resolver UIs,
The resolver is implemented via an iframe created within the app that is shown and hidden, with the recommendation that:
FDC3 should provide a default, bare-bones intent resolver UI implementation
That default implementation should be overridable by a DA that provides a URL to load instead OR it should also be able to indicate that it does NOT need a UI (e.g. because it is displaying apps in iframes and can do the rendering itself).
That an app developer can also override the implementation (taking precedence over the DA override, unless the DA disabled it as not needed).
Either an app developer or DA may provide CSS to override positioning
On discussion, there was consensus that the FDC3 module probably shouldn't include UIs and have dependencies on UI frameworks.
Hence, the default implementation will either need to be free of all frameworks OR provided in a separate module OR hosted at a predefined URL.
A message schema is needed for the exchange of information between the DA Proxy and Intent Resolver UI to communicate what needs resolving/the options for doing so, and the users choice of an option (or cancellation from the resolver dialog).
There was a similar discussion of channel selectors
A similar approach is used (an iframe is created in the window and content loaded into it)
The POC is not as far along and harder to make look reasonable
It was suggested that no new messages are needed as the protocol already handles most channel events - however on later examination it becomes obvious that the proy DOES need to communicate with UI elements it renders in iframes.
@kriswest reported that his firm had implemented a floating channel selector some years ago, but it was retired as it was unpopular with users. The Later work on window management resulted in iframes being used to render one or more apps in a window, which allows for the channel selector to appear there instead.
More collaborators are desired for completing the POC codebase and eventually translating the DA proxy and message schemas to the FDC3 NPM module.
Action Items
[x] @kriswest Attempt TS code generation from the protocol schemas and compare to Rob's custom messages and Terry's TS message types
[ ] @kriswest add messages for Intent resolver, channel selector UI handling and connection protocol
[ ] @kriswest to apply changes to deal with as many of the comments on the docs PR (#1191) as possible.
[x] @kriswest and @robmoffat to arrange a session with @julianna-ciq to introduce her to the POC codebase and get her involved in furthering the POC.
[ ] @robmoffat to seek out and recruit other potential POC collaborators
Group overview
Group convened to discuss how to enable FDC3 use in a web browser, without the use of a browser extension (such as fdc3-desktop-agent or a container).
Issue: https://github.com/finos/FDC3/issues/896 Mailing list discussion: https://groups.google.com/a/finos.org/g/fdc3/c/jCvlLjokBLs
In a recent email on the FDC3 mailing list, @kriswest wrote:
... I also want to add that there is clearly significant interest in the community in enabling FDC3 use on the web. There is a strong use case in that it would enable better onboarding journeys with less drop-off (where you use an app on the web with others before adopting a desktop container or similar).
and:
But there are also additional challenges such as how to make the API available reliably without importing a proprietary module from a particular vendor into every app, how to deal with more than one implementation of API/Desktop Agent in the browser at once, how to do this reliably and securely within the browser sandbox etc.. Work needs to be done in the Standard to solve these issues and to make web browser use possible in a future FDC3 Standard version - which I believe is possible (and likely to involve using a vendor-agnostic FDC3 NPM module to detect and connect to API implementation(s)). However, we're going to need to do that work to enable the aforementioned API implementations to be compliant and if we fail to hold the line now on compliance with the current version of the FDC3 Standard, that may never happen.
Shared doc with current draft: https://tick42-my.sharepoint.com/:w:/g/personal/finsemble_datastore_interop_io/EZ0dfTCdRlJCnIF3C_1Oit0BF3fsXyvlMbisXp722DC9Kg?e=H2y7fn
Relevant issue tags
Current open issues that relate to the above concepts with the label:
Meeting Date
Thursday 18th April 2024 - 11am (US eastern timezone EDT) / 4pm (London, BST)
Zoom info
Meeting notices
FINOS Project leads are responsible for observing the FINOS guidelines for running project meetings. Project maintainers can find additional resources in the FINOS Maintainers Cheatsheet.
All participants in FINOS project meetings are subject to the LF Antitrust Policy, the FINOS Community Code of Conduct and all other FINOS policies.
FINOS meetings involve participation by industry competitors, and it is the intention of FINOS and the Linux Foundation to conduct all of its activities in accordance with applicable antitrust and competition laws. It is therefore extremely important that attendees adhere to meeting agendas, and be aware of, and not participate in, any activities that are prohibited under applicable US state, federal or foreign antitrust and competition laws. Please contact legal@finos.org with any questions.
FINOS project meetings may be recorded for use solely by the FINOS team for administration purposes. In very limited instances, and with explicit approval, recordings may be made more widely available.
A Discussion Group has no direct decision-making power regarding the FDC3 standard - rather it is intended that anything they propose or work on will result in proposals (via Github issues and PRs) for the Standards Working Group participants to consider and vote on for inclusion in the standard.
Participation Requirements
Note: Meeting participants are expected to accept the terms of the FDC3 license (Community Specification License), understand the governance process and have a CLA in place.
Please click the following links at the start of the meeting if you have not done so previously.
Tracking Attendance
Note: Meeting participants are expected to add a comment to this GitHub issue in order that we can track attendance of FDC3 project meetings. Please do this at the start of the meeting.
Agenda
1174
Minutes
Action Items
Untracked attendees