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.

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

Clarification re repeated addContextListener and addIntentListener calls #1394

Open
wants to merge 8 commits into
base: main
Choose a base branch
from

Conversation

kemerava
Copy link
Contributor

Closes #1390

Based on the discussion on the issue, adding the clarification to the standard on the expected behavior when multiple calls are made to addContextListener and addIntentListener

@michael-bowen-sc

@kemerava kemerava requested a review from a team as a code owner October 18, 2024 16:18
Copy link

netlify bot commented Oct 18, 2024

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

Name Link
🔨 Latest commit 3acaa23
🔍 Latest deploy log https://app.netlify.com/sites/fdc3/deploys/671bb977940a6c00085cd744

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.

Good job! Personally, I think that we triggering of all listeners is currently a MUST and should remain so (meaning the SHOULDs in the this PR become MUSTs to explicitly state that).

I also wonder if we need to add a comment about reconnection. If a web app is refreshed it needs to add new handlers as the old ones will be fone - the DA should be tracking the lifecycle of the app and considering them to have been removed if the app reloads/navigates/reconnects. That generally only applies to web apps as most others don't 'reconnect' or 'refresh' in a way that would wipe out their handler functions

@@ -174,6 +174,8 @@ If, when this function is called, the channel already contains context that woul

Optional metadata about each context message received, including the app that originated the message, SHOULD be provided by the desktop agent implementation.

Adding multiple context listeners on the same or overlapping types (i.e. specific `contextType` and `null` type) SHOULD be allowed, and SHOULD trigger all ContextHandlers when a relevant context type is broadcast on the current channel.
Copy link
Contributor

Choose a reason for hiding this comment

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

We should probably upgrade this to a MUST or it allows variation between implementations that may be undesirable. There is no error to return as an alternative so an app will have no way to know if a new listener was added or an existing one replaced (until they can observe it not receiving something it should).

My preference would be to have consistent behavior and fos us to add a conformance test for it in both:

Copy link
Contributor Author

@kemerava kemerava Oct 25, 2024

Choose a reason for hiding this comment

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

Changed the SHOULD to MUST

Copy link
Contributor Author

@kemerava kemerava Oct 25, 2024

Choose a reason for hiding this comment

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

I also added the test definitions to the files you mentioned; do you think it is also worth adding the addIntentListener case to the Basic tests?

docs/api/ref/DesktopAgent.md Outdated Show resolved Hide resolved
docs/api/spec.md Outdated Show resolved Hide resolved
src/api/Channel.ts Outdated Show resolved Hide resolved
src/api/DesktopAgent.ts Outdated Show resolved Hide resolved
src/api/Errors.ts Outdated Show resolved Hide resolved
@bingenito
Copy link
Member

I see a mix of resolvererror and resolveerror in text and anchor links.

src/api/DesktopAgent.ts Outdated Show resolved Hide resolved
@kriswest
Copy link
Contributor

I see a mix of resolvererror and resolveerror in text and anchor links.

Good 👀 @bingenito - I missed several of those. Added to suggestions

Co-authored-by: Kris West <kris.west@interop.io>
@kemerava
Copy link
Contributor Author

Good job! Personally, I think that we triggering of all listeners is currently a MUST and should remain so (meaning the SHOULDs in the this PR become MUSTs to explicitly state that).

I also wonder if we need to add a comment about reconnection. If a web app is refreshed it needs to add new handlers as the old ones will be fone - the DA should be tracking the lifecycle of the app and considering them to have been removed if the app reloads/navigates/reconnects. That generally only applies to web apps as most others don't 'reconnect' or 'refresh' in a way that would wipe out their handler functions

@kriswest In terms of the reconnection, I think that there a case which can to be made for Desktop Agent to keep the listeners in memory at least for a short period of time. Not sure as much for web apps, but for others, depending on which method of connection is used, it is possible that the app temporarily lost the connection, and I am not sure if it makes sense to always ask apps to reconnect.
This is my scenario, for example, if Desktop Agent is determining the app connection based on the heartbeats from the app, and then the app disconnects, then the behavior is slightly undererministic, where Desktop Agent might have already "noticed" that the app has disconnected, and removed the listeners, or it has not, and then the listeners are still there, and then the app unnecessarily sending more calls to DA. Of course, even with keeping listeners in memory we cannot guarantee for sure if that senario would not happen. We can also think about introducing an endpoint which would list all the listenerIds which DA has for the given app, this way the app can verify if it is missing some listeners or if there are some which are no longer needed and can be cleaned up
Please let me know what you think!

bingenito
bingenito previously approved these changes Oct 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Clarify: What should happen on repeated listener addition for the same contextType/intent
3 participants