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.

Sign up for GitHub

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

Jump to bottom

Standard WG Meeting - April 28, 2022 #683

Closed
16 of 17 tasks
kriswest opened this issue Apr 28, 2022 · 16 comments
Closed
16 of 17 tasks

Standard WG Meeting - April 28, 2022 #683

kriswest opened this issue Apr 28, 2022 · 16 comments
Labels
indexed When a meeting attendance is being tracked meeting Standard WG Meeting

Comments

@kriswest
Copy link
Contributor

kriswest commented Apr 28, 2022 •
edited
Loading

Date

Thursday 28 April 2022 - 10am EST / 3pm GMT

WebEx info

More ways to join

  • Join by video system:
  • Join by phone
    • +1-415-655-0003 US Toll
    • +44-20319-88141 UK Toll
  • Access code: 665 568 411

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.

Agenda

Minutes

  • Updates on timeline and outstanding projects for FDC3 2.0
    • Timeline
      • PRs for inclusion into 2.0 need to be ready for before the next SWG meeting (end of May)
      • PRs should be circulated before the meeting
      • Votes in the meeting / via email after the meeing to go into pre-draft
      • Pre-draft to be prorposed for adoption prior to June SWG
      • Then v2.1 and beyond :)
    • Proposal for the FDC3 project to adopt the new FINOS Standards Governance model (including the Community Specification License) #412
      • We've adopted chunks of CSL but not all
      • Plan (on advice from FINOS/LF) to immediately adopt CSL after v2.0 released
      • Contributions after v2.0 would be on the new license
      • Any pending contributions will need explicit approval from contibutors to switch to CSL (or not be merged)
      • After adopting CSL there will be a requirement to wait 45 days from completion of a vote to adopt a new version to it being published to allow firms to search their databses for overlapping patents etc.
    • Formal specification project
      • PR 679 to improve quality of navigation etc. of standard docs is in progress
        • [WIP] 491 formal spec reorg #679
        • you can clone the branch and run the documentation locally if you want to explore: 
            yarn
  cd website
  yarn start
        • call for firms to provide information to go into implementations page - to be circulated via email
      • 533 experimental features #549
        • awaiting vote and merge by maintainers
    • Contexts & Intents discussion group proposals
      • 4 ready to go, 6-7 more being worked on over the next few weeks ready for the next SWG meeting
    • AppD discussion group proposals
      • A number of issues have been agreed and moved to PRs, others are still being discussed.
      • PRs are being consolidated into a single branch for presentation to SWG as most are updating the same document (schema YAML file)
  • Proposal of a new FDC3 maintainer: Vinay Mistry
    • @kriswest and @rikoe proposed Vinay Mistry from Symphony as an FDC3 maintainer.
      • To be circulated via email for election vote.
  • Deprecate use of the string name field in favour of AppMetadata #506
    • @bingenito getting rid of the union type (TargetApp) would be good as its an ugly interface in non-javascript implementations.
    • @nkolba Doesn't the AppMetadata type duplicate the purpose of the appId records?
    • @kriswest AppMetadata is a deliberate subset of an appId record (except for the instanceId field) so an appD record can be directly passed as AppMetadata, it'll just have some extra fields. When it was added a decision was made to NOT include everything from teh appD record, only what is necessary.
    • @nkolba There are too many IDs/fields in AppMetadata, which are necessary to pass? e.g. Why would you pass title in and what behavior would you expect?
      • @kriswest The issue originally sought to encourage the use of AppMetadata objects returned by the desktop agent, so you don't have to worry about that. It should also be possible to clearly indicate whats used and when in docs.
        • @thorsent suggested splitting the AppMetadata type so that a smaller type (e.g. AppTarget) expresses the requirements for targets etc., why AppMetadata could extend it for responses. That way AppMetadata can still be passed in, but requirements are clear.
      • @kriswest AppMetadata also carries the instanceId field, which allows API calls to target either new instances of apps or existing ones, without adding new API signatures.
      • Alternative suggestion: Allow apps to pass either name or appId as string parameters and put the onus on the Desktop Agent to disambiguate
        • @kriswest and @bingenito pointed out that there are several practical issues with this:
          • changing the meaning / data passed to the parameter is a harsh change
          • there is no guarantee that name will not collide with appID from other appDs
          • appId is the primary ID used in AppD, switching to it would better align two parts of the standard.
          • appId supports full qualification, making it globally unique and the only way to guarantee avoidance of id collisions, which name is vulnerable to (both within and between appDs).
    • A number of participants suggested the full qualification of appIDs should be recommended (SHOULD).
    • @kriswest to move to a PR and show how this would work in documentation.
  • Require propagation of originating application identity on context/intent handlers #520
    • @kriswest to move to PR (unless a volunteer comes forward to take it on).
    • Document as optional/recommended (SHOULD) - pass null or undefined if not supported.
  • Standardise auto-receipt of current context on join/addContextListener in DesktopAgent and Channel #511
    • Several participants reported that user like auto-broadcast of context on joining user channels (popular feature)
      • App channels have a slightly different use case however
    • Several participants commented that it did feel inconsistent that we don't auto-broadcast on adding a context listener to an app channel and generally we should avoid inconsistency
      • However, another participant related that there are use cases for NOT auto-broadcasting context when adding a listener to an app channel and that this behavior can be implemented by an app with getCurrentContext
    • @kriswest agreed to close (not the most important issue ahead of use)
  • Provide details about support for optional API features in ImplementationMetadata #636
    • Not discussed in details as @kriswest suggested we do so after compliance info has been collated and the list of optional features is known
  • Allow an app to retrieve its own AppMetadata #603
    • Allowing an app to have parity with other apps over its own identity (other apps will discover through findIntent and surfacing of originating app identities) was deemed a sufficient use case
    • Rather than expanding the DesktopAgent API surface area, adding this data as a field in ImplementationMetadata was preferred. This object is returned asynchronously in FDC3 2.0

Action Items

Untracked attendees

Full name Affiliation GitHub username
@bingenito
Copy link
Member

bingenito commented Apr 28, 2022 •
edited
Loading

Brian / Morgan Stanley

@mattjamieson
Copy link
Contributor

👋

@Julia-Ritter
Copy link
Contributor

Julia / FINOS

@thorsent
Copy link
Contributor

Terry / Cosaic

@openfin-johans
Copy link
Contributor

Johan / OpenFin 🎁

@hampshan
Copy link

Andrew Hampshire / UBS

@tpina
Copy link
Contributor

tpina commented Apr 28, 2022

Tiago / Cosaic

@robmoffat
Copy link
Member

Hello!

@hughtroeger
Copy link
Contributor

Hugh / FactSet

@Qiana-Citi
Copy link

Qiana / Citi

@sarahaislinnstone
Copy link

sarah stone / cosaic

@WatsonCIQ
Copy link
Contributor

Chris Watson / Cosaic

@timjenkel
Copy link

Tim / Wellington

@mistryvinay
Copy link
Contributor

Vinay / Symphony

@kriswest
Copy link
Contributor Author

Kris / Cosaic

@kriswest kriswest mentioned this issue Apr 29, 2022
Closed
This was referenced May 17, 2022
Merged
Merged
Closed
@github-actions github-actions bot added the indexed When a meeting attendance is being tracked label May 26, 2022
@Julia-Ritter
Copy link
Contributor

Untracked attendees:

  • Nathan / Flextrade
  • Dimiter Georgiev / Symphony
  • Ben Gold / Wellington
  • Dominic GIFFORD / (S&P Global)
  • Bertrand Laporte / Symphony
  • William Shotton / RBC
  • Nick Kolba
  • Riko Eksteen / Adaptive

@kriswest kriswest mentioned this issue Nov 28, 2022
Closed
kriswest added a commit that referenced this issue Nov 28, 2022
@kriswest
Confirm that (2.0) App channels do not re-play past contexts when a l…
f0a93be 
…istener is added

Small addition to one of the app channel tests - we need to confirm that App Channels, listened to via the Channel interface do not auto-replay context messages (as System/User channels listened to through the fdc3/Desktop Agent interface do).

A different PR adds this to the 1.2 test cases.

Background:

The Standards Working Group re-affirmed under issue #511 at meeting #683 that the difference in the behaviour of the fdc3/DesktopAgent and Channel interfaces was intentional and necessary to implement certain use cases with App Channels. It was decided that this would not change in FDC3 2.0, hence it remains the case in 2.0.
@kriswest kriswest mentioned this issue Nov 28, 2022
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
indexed When a meeting attendance is being tracked meeting Standard WG Meeting
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests