Skip to content

Standard WG Meeting - January 23rd, 2025 #1499

New issue
New issue
Closed
Meeting
Closed
Standard WG Meeting - January 23rd, 2025#1499
Meeting
Labels
Standard WG Meetingmeeting
@kriswest

Description

@kriswest
kriswest
opened on Jan 23, 2025

Date

Thursday 23rd January 2025 - 10am (US eastern timezone EST) / 3pm (London, GMT)

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 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.

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

  • @kriswest provided a status update on FDC3 for the Web and the 2.2 alpha release (as detailed in the agenda above).
    • The test policy for FDC3 NPM modules was reviewed and no objections to it were raised - other than a duplicated line in the package breakdown.
    • Testing and feedback on the alpha NPM module was requested from participants
  • @kriswest proposed @julianna-ciq as a new fdc3-maintainer on behalf of interop.io (and his own move to NatWest Bank) and asked for the consent of the SWG to appoint her, which was given.
    • A brief discussion of the need for further maintainers and editors was also held and firms invited to put forward canidates.
    • @robmoffat asked if @Roaders would be interested in becoming a maintainer - @kriswest to arrange time with @Roaders to discuss the role.
  • Proposal to add Go (GoLang) language binding #1482
    • A brief overview of the Go binding proposed by @kemerava was provided
      • There is as yet no accompanying repo for the binding - however, Go interfaces work differently than in conventional OOO languages in that they don't have to be explicitly implemented. @kemerava has commented that she can provide such a repo, if someone else in the community would find it useful - however it is less necessary than in other languages.
    • Consent from the SWG was requested for adopting a Go bindy, which was received.
    • The FDC3 maintainers requested support from any Go developers in the FDC3 community in reviewing this contribution, due to a lack of experience with Go on the maintainers team (apart from @kemerava)
  • Should the desktop agent support both unqualified appIds and fully qualified ones? #1475
    • An overview of the issue was provided: AppIds are unique within an appD, but maybe non-unique across appDs. The appD specification introduces the concept of fully qualified appIds (where the @domain-of-appd.com is appended to the appId) to deal with this and make them globally unique. However, the FDC3 (Desktop Agent) API does not address full qualification nor any logic for mapping or resolving between unqalified and fully qualified app Ids - they are generally just treated as string identifiers.
    • This leads to a situation where the same application may be referred to by two different strings (e.g. myAppId and myAppId@myAppD.com) that may not be recognized as related or equivalent by a Desktop Agent.
    • This was identified as problematic when working with the FDC3 conformance framework, which hard codes appIds for its test application, unqualified. By extension, two different Desktop Agent implementations can be correct according to the specification but act differently and require different versions of the conformance test application code (and any other applications which work with predefined appIds) - this is obviously undesirable.
    • The meeting resolved that a PR should be raised proposing resolution logic. For example, if an unqualified appId is received as a target for a raised intent but not found via a simple string match, then it can be matched to fully qualified Ids by splitting the fully qualified IDs on the @ to extract the first component (the unqualified appId). If a single application match is found it may be used. If multiple matching fully qualified IDs are found then this should be handled in the same way that multiple instances are resolved - show an intent resolver or apply another suitable resolution procedure.
    • This would be an additive change that could be applied in FDC3 2.3 - where an alternative proposal of requiring all DAs to use full qualification would be breaking and require an FDC3 3.0 version to be created.
    • @Roaders also indicated that they would explore such resolution procedures as they work on conformance testing of their implementation, rather than asking FINOS to provide or adopt a version of the conformance test framework that works with full-qualified appIds.
  • Clarify that Context types are defined in JSON and may be handled differently in specific API bindings #1486
    • @kriswest provided an overview of the issue and the confusion it had caused:
      • The context specifications are based on JSON.
      • API bindings may implement their own bindings or models for Context objects to simplify working with them in an idiomatic style for that language (as is the case in both the .NET and proposed Go binding). They will generally need to be able to convert to and from the JSON encoding in order to exchange messages through a Desktop Agent with other bindings.
      • The Typescript Context bindings are very similar to the raw JSON, but (for example) since 2.0 have included date fields which are ISO 8601 strings in JSON and Date objects in TypeScript/JavaScript - the parsing code provided in ContextTypes.ts file (generated by QuickType) handles conversion from the String type to Date, while simple stringification (JSON.stringify(someContext)) already converts Date objects to ISO 8601 strings (for example).
        • It is likely that this is not implemented by a number of Desktop Agents, but also changing this behaviour would be breaking.
        • The issue proposes that we add clarifying language to the Context AND API overviews to explain the difference between the JSON schemas and specific API bindings.
        • @Roaders and @kriswest to explore comparisons between string encodings of Dates and Date objects in JavaScript/TypeScript and to report back
        • PR to be drafted to add clarifying language to the FDC3 API and Context Specs
  • The meeting concluded before the final 3 issues were discussed, a very light introduction to each was provided for participants to consider for a future meeting.

Action Items

Rolled over from previous meetings:

Untracked attendees

Full name Affiliation GitHub username

Metadata

Metadata

Assignees

No one assigned

    Labels

    Standard WG Meetingmeeting

    Type

    Meeting

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions