8000 (WIP) implement addIntentListenerWithContext by Roaders · Pull Request #1590 · finos/FDC3 · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

(WIP) implement addIntentListenerWithContext #1590

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.

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

Closed
wants to merge 3 commits into from

Conversation

Roaders
Copy link
Contributor
@Roaders Roaders commented May 9, 2025

Describe your change

Adds a new function addIntentWithContextListener to the DesktopAgent interfaces and implements it within DesktopAgentProxy

Related Issue

resolves #1545

Contributor License Agreement

  • I acknowledge that a contributor license agreement is required and that I have one in place or will seek to put one in place ASAP.

Review Checklist

  • Issue: If a change was made to the FDC3 Standard, was an issue linked above?
  • CHANGELOG: Is a CHANGELOG.md entry included?
  • API changes: Does this PR include changes to any of the FDC3 APIs (DesktopAgent, Channel, PrivateChannel, Listener, Bridging)?
    • Docs & Sources: If yes, were both documentation (/docs) and sources updated?

      JSDoc comments on interfaces and types should be matched to the main documentation in /docs
    • Conformance tests: If yes, are conformance test definitions (/toolbox/fdc3-conformance) still correct and complete?

      Conformance test definitions should cover all required aspects of an FDC3 Desktop Agent implementation, which are usually marked with a MUST keyword, and optional features (SHOULD or MAY) where the format of those features is defined
    • Schemas: If yes, were changes applied to the Bridging and FDC3 for Web protocol schemas?

      The Web Connection protocol and Desktop Agent Communication Protocol schemas must be able to support all necessary aspects of the Desktop Agent API, while Bridging must support those aspects necessary for Desktop Agents to communicate with each other
      • If yes, was code generation (npm run build) run and the results checked in?

        Generated code will be found at /src/api/BrowserTypes.ts and/or /src/bridging/BridgingTypes.ts
  • Context types: Were new Context type schemas created or modified in this PR?
    • Were the field type conventions adhered to?
    • Was the BaseContext schema applied via allOf (as it is in existing types)?
    • Was a title and description provided for all properties defined in the schema?
    • Was at least one example provided?
    • Was code generation (npm run build) run and the results checked in?

      Generated code will be found at /src/context/ContextTypes.ts
  • Intents: Were new Intents created in this PR?

THIS SOFTWARE IS CONTRIBUTED SUBJECT TO THE TERMS OF THE FINOS CORPORATE CONTRIBUTOR LICENSE AGREEMENT.

THIS SOFTWARE IS LICENSED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE AND ANY WARRANTY OF NON-INFRINGEMENT, ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. THIS SOFTWARE MAY BE REDISTRIBUTED TO OTHERS ONLY BY EFFECTIVELY USING THIS OR ANOTHER EQUIVALENT DISCLAIMER IN ADDITION TO ANY OTHER REQUIRED LICENSE TERMS.

@Roaders Roaders requested a review from a team as a code owner May 9, 2025 15:17
Copy link
netlify bot commented May 9, 2025

Deploy Preview for fdc3 failed. Why did it fail? →

Name Link
🔨 Latest commit 46af4fc
🔍 Latest deploy log https://app.netlify.com/sites/fdc3/deploys/6821ee7b2117830008039a6a

@Roaders
Copy link
Contributor Author
Roaders commented May 9, 2025

I think that this is all the implementation that is required - pretty minimal actually. Before proceeding to tests and documentation I wanted to get an idea that this is the correct approach. Does this look good so far?

Once I get some clarification that this looks somewhat correct I'll start on the documentation and unit tests.

Will conformance tests and cucumber tests be required in this PR as well?

@Roaders
Copy link
Contributor Author
Roaders commented May 9, 2025

I guess this should probably be merged into a 2.3 specific branch?

Copy link
Contributor
@kriswest kriswest left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like a good start, a few things to think about:

@@ -351,6 +351,66 @@ export interface DesktopAgent {
*/
addIntentListener(intent: Intent, handler: IntentHandler): Promise<Listener>;

/**
* Adds a listener for incoming intents raised by other applications, via calls to `fdc3.raiseIntent` or `fdc3.raiseIntentForContext. If the application is intended to be launched to resolve raised intents, it SHOULD add its intent listeners as quickly as possible after launch or an error MAY be returned to the caller and the intent and context may not be delivered. The exact timeout used is set by the Desktop Agent implementation, but MUST be at least 15 seconds.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You could probably shorten this and reduce duplication by referring to addIntentListener() and explaining the difference?

private readonly context: string[] | null,
action: IntentHandler,
messageExchangeTimeout: number
) {
super(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Theres more to think about here: how does the Desktop Agent know what contexts are being listened for (and hence how to filter intent resolution)?
The AbstractListener is what's notifying the Desktop Agent about the new listener and its only being passed the intent ({ intent }). To resolve, add the contexts array on line 23 if not null (I'd omit it otherwise) then update the addIntentListenerRequest schema to support the extra property in the payload. I'd make it optional (don't add to the required array) but don't allow null values (so type is just array).

@kriswest
Copy link
Contributor
kriswest commented May 9, 2025

@Roaders you should have push permissions on fdc3 repo now, so you could merge this into branch of the FINOS repo and open a new PR with that branch. That way the CI Tests and Coverage job will actually pass - we need to do some work on the GitHub action to stop it failing on PRs from forks 😞

Co-authored-by: Kris West <kris.west@interop.io>
@Roaders
Copy link
Contributor Author
Roaders commented May 9, 2025

Thanks for the responses @kriswest . I had been thinking earlier in the day about the DA updating it's own inte 8000 rnal representation of the App Directory and that completely fell out of my head when I was working on this. As you say I'll have to update the schema for the addIntentListener message so that the DA has the additional information.

I will push to a branch in the finos repo and recreate the PR from there. Thanks for the other comments.

@kriswest
Copy link
Contributor
kriswest commented May 9, 2025

I guess this should probably be merged into a 2.3 specific branch?

A PR to main is the right thing to do. main represents the current 'pre-draft' of the next version of the standard.

@kriswest kriswest changed the title (WIP) implement addIntentWithContextListener (WIP) implement addIntentListenerWithContext May 12, 2025
Co-authored-by: Kris West <kris.west@interop.io>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support specifying supported context when registering an intent listener
2 participants
0