Standard WG Meeting - April 28, 2022

kriswest commented 2 years ago

Date

Thursday 28 April 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

[x] Convene & roll call, review meeting notices (5mins)
[x] Review action items from previous meeting (5mins)
- 637
[x] Updates on timeline and outstanding projects for FDC3 2.0 (10 mins)
- Timeline
- proposed deadline for pull requests: May SWG meeting
- proposed fdc3 pre-draft adoption vote: June SWG meeting
- 412
- Formal specification project
- 679
  - Call for implementation (app and platform provider) details
- 549
- Contexts & Intents discussion group proposals
- AppD discussion group proposals
[x] Proposal of a new FDC3 maintainer: Vinay Mistry (<5 mins)
[x] #506 (10 mins)
[x] #520 (10 mins)
[x] #511 (5 mins)
[x] #636 (5 mins)
[x] #603 (5mins)
[x] Adjourn

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 :)
- 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
  - 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
- 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.
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.
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.
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)
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
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
- @kriswest to update issues and raise PR

Action Items

[x] @kriswest Circulate call for firms to provide information to go into implementations page via email.
[x] @kriswest Circulate proposal of election of Vinay Mistry from Symphony as an FDC3 maintainer.
[x] @kriswest Update #506 (split AppMetadata type into AppTarget and AppMetadata), document thinking and raise PR.
[x] @kriswest raise PR to resolve #520, document as SHOULD.
[ ] @kriswest collate compliance require,ents/optional features to flesh out proposal for #636
[x] @kriswest raise PR to resolve #603, with apps metadata added to ImplementationMetadata Object
[x] ALL PRs for inclusion in 2.0 should be complete before next meeting and circulated for review in advance to facilitate efficient voting on them for inclusion