You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 [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.
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
Convene & roll call, review meeting notices (5mins)
@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
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
@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
The text was updated successfully, but these errors were encountered:
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:
Meeting Date
Thursday 29th August 2024 - 9am (US eastern timezone EDT) / 2pm (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 [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
IntentMetadata.displayName
made optional as displayName is deprecated in Intent Standard: Make IntentMetadata.displayName optional as its deprecated #1280Minutes
Recent Changes to the proposal
Add heartbeat messages: App Liveness Check #1320
onClose
event on aMessagePort
(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 closingonbeforeunload
- this is not correct as thats a cancellable event and other handlers might cancel closeonunload
fits better, but is deprecated and unreliable - although we are aware of/planning for unreliability with the heartbeat messages..pagehide
wherepersisted == false
: App Liveness Check #1320 (comment)heartbeatResponseRequest
toheartbestAcknowledgment
frozen
state (chrome memorySaveer mode) as they may not be able to to respond to heartbeat messages until aresume
event. Again see the pagelifecycle API and notes on the issue App Liveness Check #1320 (comment)Question: Disposal/Teardown patterns in FDC3 #1263
Next steps
Action Items
heartbeatResponseRequest
toheartbestAcknowledgment
pagehide
when the event haspersisted == false
and an example of using the heartbeat messages (needs support for automated responses ingetAgent()
implementation - DA implementations can then use the heartbeat as they see fitRolled over and/or still in progress:
window.location.href
should be used by default, andwindow.location.href
should always have a matching origin to the specified URL.Untracked attendees
The text was updated successfully, but these errors were encountered: