Standard WG Meeting - Nov 30th, 2022

[kriswest]

Date

Wednesday 30 Nov 2022 - 10am EST / 3pm GMT

WebEx info

• Meeting Link
  Meeting number: 665 568 411

More ways to join

• Join by video system:
  • Dial 665568411@finos.webex.com
  • You can also dial 173.243.2.68 and enter your meeting number
• 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

• Convene & roll call, review meeting notices (5mins)
• Review action items from previous meeting (5mins)
• OSFF NY Thursday 8th December (2mins)
• Update on FDC3 Conformance testing project progress (5mins)
• Discussion of open issues (40mins)
  (will not get to all, the remainder to roll over to future meetings):
  • Are you ready yet? Adding defined (or at least bounded) timeouts to the FDC3 Desktop Agent API #866
  • Allow Desktop Agent To Join Multiple Channels #242
  • Reset context  #301
  • Upgrade exposure of originating app identity to a requirement (MUST) from recommended (SHOULD) #735
  • Add vendor agnostic default window size and position settings to the App Directory app definition format #564
  • Add save and restore state API calls - so FDC3 apps can fully participate in save and restore layout #386
  • Provide Notification API's #387
  • Provide better documentation and examples for AppD auth support #559
  • Create an AppD reference implementation #563
• AOB & Adjourn (3mins)

Minutes

• Review action items from previous meeting (5mins)

  • A number of action items were rolled over. The maintainers are currently distracted with the conformance program effort, however, many of the action items are small clarifications and PR that will be dealt with as a batch at some point in the near future.

• OSFF NY Thursday 8th December

  • All were reminded about the upcoming event in NYC and brief tour of FDC3 related presentations was provided.

• Update on FDC3 Conformance testing project progress

  • An overview of the framework and testing program and an update on implementation progress was provided by @robmoffat
    • 1.2 conformance tests are about complete, with 3 Desktop Agent implementations about ready for their formal tests and badging. Look for an announcement at OSFF in NYC
    • A lot of progress has been made on 2.0 tests:
      • Cases drafted and awaiting review/approval by FDC3 maintainers: Conformance 2.0 Test Pack #857
      • Implementation is well underway
  • A question was raised regarding plans to offer a similar program for the certification of applications
    • FINOS do have plans in this area - although automated testing is far more difficult to implement for apps. How to provide a similar program for apps is an area of active thought.
  • A question was raised regarding plans to test/certify the FDC3 chrome browser extension fdc3-desktop-agent
    • Nothing prevents this from being certified, but it may need some maintenance work to achieve certification. This is unlikely to happen prior to OSFF.
  • The discussion moved on to the use of FDC3 within a web-browser,
    • Which is not currently possible due to the fact FDC3 requires an implementation to be injected into apps, which browser-security models are specifically designed to prevent (cross-origin code injection). Proprietary implementations do exist, but require code to be built into applications - thereby falling outside the current Standard.
    • Several participants believe that:
      • This is a solvable problem, through additions to the Standard and its NPM module.
        • @kriswest An issue will need to be raised for discussion - to be taken on either via the FDC3 SWG or a discussion group spun off to develop a proposal.
      • Enabling the use of FDC3 within a web-browser, in a Standards compliant/vendor agnostic fashion will increase the uptake of the FDC3 Standard.

• Are you ready yet? Adding defined (or at least bounded) timeouts to the FDC3 Desktop Agent API #866

  • An introduction to this issue was provided - including issues it causes for conformance testing (unknown/unbounded timeouts mean the conformance framework doesn't know how long it needs to wait to complete raiseIntent and open tests that should return errors based on Desktop Agent defined timeouts.)
  • A participant confirmed that they definitely have/have observed applications that require extended periods to start.
  • There was consensus that introducing a recommended and a required timeout (bound on the timeout used) would encourage app vendors to implement apps such that they can receive intents and contexts more quickly - holding them until ready to use them if necessary.
    • Owing to the confirmed existence of apps requiring long bootstrapping/start-up times it was request that DAs MAY also offer configuration to extend the timeouts beyond the bounds established - but that this should be configurable rather than a default.
  • Consent was sought a received to raise a PR to add recommended and required timeouts to the standard as an action item.

• Allow Desktop Agent To Join Multiple Channels #242

  • A further overview of this issue and associated use cases was provided.
  • Both @kriswest and another participant indicated that they had this use case and had implemented support for it in a desktop agent in the past.
    • Both also observed that directional membership of a channel (i.e. only listening or only broadcasting) was also demonstrated - although the user experience for setting directional membership is overly complex.
  • @kriswest requested further investigation of whether the use cases were still currently and promised to report back based on queries to their own client-base. Another participant also promised to report back. Confirmation of or more detail on the use case should be posted to the issue to inform further discussion.
  • Consent was sought and received to leave the issue open again, pending the addition of more use case information.

• Reset context  #301

  • An overview of the issue and use case was provided - including previously proposed solutions.
    • Where filters are created and set by incoming context messages of a particular type - then a message of that type could/should be used to reset context, for example by providing an empty id field or other entry that would normally uniquely identify an entity.
    • Alternatively the fdc3.nothing type may be used to explicitly represent the absence of a context and maybe listened for to implement a reset.
  • Given the available workarounds, there was no appetite to introduce new API functionality to reset context.
  • Consent was sought and received to close the issue.

• Upgrade exposure of originating app identity to a requirement (MUST) from recommended (SHOULD) #735

  • A brief history of 'originating app details' was provided, including:
    • an indication that it was specifically avoided in early versions of FDC3 to promote open interop and prevent 'picking and choosing' of who to interoperate with.
    • However, this was challenged in FDC3 2.0 with some firms indicating that they could not participate in context sharing without an indication of source. This resulted in an optional/recommended (SHOULD) feature being included to identify the origin of messages.
  • A decision needs to be made by the FDC3 community as to what affects FDC3 uptake more:
    • Providing originating app context - but reducing the openness of interop), or
    • NOT providing originating app context - but potentially losing some participants.
  • There was insufficient time to debate the topic - but all were encouraged to think on it to prepare for a future debate.

Action Items

• @kriswest or a volunteer, Raise a PR to resolve Are you ready yet? Adding defined (or at least bounded) timeouts to the FDC3 Desktop Agent API #866
  • Add:
    • a recommended maximum time after start-up within which apps SHOULDadd context and intent listeners
    • a required maximum time after start-up within which apps MUST add context and intent listeners
    • statement that Desktop Agents MAY be configured to extend timeouts applied to open or raiseIntent functions.
• Participants with use cases that require multiple or directional channel membership to post details on issue Allow Desktop Agent To Join Multiple Channels #242 to inform future discussion.
• @kriswest Reset context  #301 to be closed.

Rolled over from previous meetings:

• @kriswest Raise a PR to resolve AppD v2 routes don't define error response samples #827
• Add error response samples to appD v2 API routes to make them more obvious in the Swagger spec for appD.
• @kriswest @nkolba @pierreneu to work on proposals/PRs demonstrating possible solutions to Question: App-specific context metadata #829. These should include example use-cases demonstrating the need for and utility of the revision
• @finos/fdc3-maintainers to investigate adding code coverage scanning to repo and to propose a unit testing policy/raise a PR to add to governance and resolve Unit Test Policy #832.
• @openfin-johans find a volunteer to help resolve FDC3 Explained: SemGrep Failures #811 - fallback to @kriswest and @WatsonCIQ if necessary
• @finos/fdc3-maintainers to review regenerate context_types after valuation correction #842 to enable NPM module release
• @kriswest or volunteer: raise PR to resolve Add /intents and /contexts endpoints to the AppD API #719
  • Add optional/recommended API endpoints for /intents and /contexts to the appD API.
• @kriswest or volunteer: raise PR to resolve The AppIntent interface incorrectly describes an intent #312
  • deprecate interop.intents.listensFor[<intentname>].displayName field in appD and AppIntent.intent.displayName in the API types and add explanation of using intent name for display to documentation.
• @kriswest or volunteer: raise a PR to resolve Deprecate appD name field and make it optional #820
  • Make name optional and deprecated in appD records and making title required.

Untracked attendees

Full name	Affiliation	GitHub username

[kriswest]

Kris West / Cosaic 🚀

[novavi]

Derek Novavi / S&P Global

[Julia-Ritter]

Julia / FINOS

[timjenkel]

Tim / Wellington

[pierreneu]

Pierre Neu / Symphony

[mistryvinay]

Vinay Mistry / Symphony

[robmoffat]

Rob/ FINOS

[hughtroeger]

Hugh / FactSet