Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FDC3 for Web Browsers Discussion group 29th Aug 2024 #1321

Open
6 of 15 tasks
kriswest opened this issue Aug 28, 2024 · 7 comments
Open
6 of 15 tasks

FDC3 for Web Browsers Discussion group 29th Aug 2024 #1321

kriswest opened this issue Aug 28, 2024 · 7 comments
Labels

Comments

@kriswest
Copy link
Contributor

kriswest commented Aug 28, 2024

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: #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:
image

Meeting Date

Thursday 29th August 2024 - 9am (US eastern timezone EDT) / 2pm (London, BST)

Zoom info

  • Join Zoom Meeting
  • Meeting ID: 969 4029 4948
  • Passcode: 636931
  • Dial-in:
    Country International Dial-in Toll-free Dial-in
    US +1 929 205 6099 (New York) 877 853 5247
    UK +44 330 088 5830 0800 031 5717
    France +33 1 8699 5831 0 800 940 415
    Find your local number https://zoom.us/u/ad2WVnBzb8

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 [email protected] 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

Minutes

  • Recent Changes to the proposal

    • @kriswest ran through all recent changes to the proposal and provided an overview.
    • A number of items were discussed or clarified for participants, and a few additional actions agreed including:
      • App identity procedures, including identityURL, actualUrl - pseudo-code needed for comparison procedure
      • Correction of a typo in broadcastEvent schema
  • Add heartbeat messages: App Liveness Check #1320

    • @kriswest provided an overview of discussions about app liveness checks, how DAs can know that an app has gone away
    • Created WCP6Goodbye message in proposal for apps to indicate closing
      • there were recent objections from the Chrome security team to the onClose event on a MessagePort (provides information on when garbage collection is occurring, which can be used to time certain attacks) which is preventing them from implementing it - unfortunate as that event would have been ideal to catch apps closing
      • POC code should attempt to call this whenever it detects an app is closing
        • Discussed using onbeforeunload - this is not correct as thats a cancellable event and other handlers might cancel close
          • onunload fits better, but is deprecated and unreliable - although we are aware of/planning for unreliability with the heartbeat messages..
          • pagelifecycle API provides other options - further notes have been added to the issue (used pagehide where persisted == false: App Liveness Check #1320 (comment)
    • Created heartbeatEvent and heartbeatResponseRequest in proposal
      • Direction is reversed vs. most other interactions (which start with a request from an app to a DA, or are events from the DA without responses
      • There was consensus that we should rename heartbeatResponseRequest to heartbestAcknowledgment
      • The heartbeat messages can be used on a repeating schedule to check if apps are liv
      • They can also be used for adHoc checks - for example are all app instances being shown in the intent resolver alive? Check and remove those that are not.
      • There maybe issues with apps that enter a frozen state (chrome memorySaveer mode) as they may not be able to to respond to heartbeat messages until a resume event. Again see the pagelifecycle API and notes on the issue App Liveness Check #1320 (comment)
        • heartbeats should be added to the proposal, but not a requirement on usage until this issue has been further explored in implementations
  • Question: Disposal/Teardown patterns in FDC3 #1263

    • There was not time to discuss this issue, but discussion at the last SWG meeting was referenced: Standard WG Meeting - August 22nd, 2024 #1317
    • The subagent proposal is unlikely to be ready for FDC3 2.2 and will be added to the scope for 2.3 - it will need to include a teardown pattern/api call for subagents.
  • Next steps

    • @kriswest to send an email to meeting participants when the first draft of the documentation is available for review. Once reviewed the proposal will be advertised to the FDC3 community ready to check that there is consensus that it should become part of FDC3 in 2.2. This should occur before the next SWG meeting.

Action Items

  • @kriswest Complete WCP and DACP documentation, Desktop Agent specs in proposal and include all clarifications
    • To include
      • Describe identity arguments (identityURL, actual URL, URL from appDirectory) and pseudo-code for comparison procedure (all elements from appD URL need to be present in identityURL, origin must match actual URL.
  • @kriswest Rename heartbeatResponseRequest to heartbestAcknowledgment
  • @robmoffat Implement app closing messages (WCP6Goodbye) in the getAgent() code, to be called on pagehide when the event has persisted == false and an example of using the heartbeat messages (needs support for automated responses in getAgent() implementation - DA implementations can then use the heartbeat as they see fit

Rolled over and/or still in progress:

  • @robmoffat @kriswest to to review @Roaders work on generating type predicates automatically using TSMorph
  • @robmoffat to look at cleaning up resources for windows and iframes that have gone away under the main proposal.
  • @Davidhanson90 to look into tear-down patterns for subagents.
  • @robmoffat to update the POC to work on URLs for identity - if not specified the current window.location.href should be used by default, and window.location.href should always have a matching origin to the specified URL.
  • @kriswest to ensure that a README and screencast video is provided on maintaining schemas and code generation.

Untracked attendees

Full name Affiliation GitHub username
@Lecss
Copy link

Lecss commented Aug 29, 2024

Alex Dumitru / Citi

@Davidhanson90
Copy link

David Hanson / Morgan Stanley 🚀

@robmoffat
Copy link
Member

Rob Moffat / FINOS

@openfin-johans
Copy link
Contributor

Johan Sandersson / Here (formerly OpenFin) 🎁

@Roaders
Copy link
Contributor

Roaders commented Aug 29, 2024

Giles Roadnight / Morgan Stanley

@hughtroeger
Copy link
Contributor

Hugh Troeger / FactSet

@kriswest
Copy link
Contributor Author

Kris West / interop.io 🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

7 participants