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

Add additional parameters to getOrCreateChannel to allow broadcast to be received by app that makes the broadcast #1407

Open
Roaders opened this issue Oct 29, 2024 · 2 comments
Labels
api FDC3 API Working Group enhancement New feature or request

Comments

@Roaders
Copy link
Contributor

Roaders commented Oct 29, 2024

Enhancement Request

Use Case:

If I have some state that I want to synchronise across multiple apps that can be set by multiple apps currently I have to add a special case to handle updating the state in the app that is broadcasting the message. This is a particular problem if disparate parts of an app publish and subscribe to these broadcast messages. Somehow the publish component would have to inform the subscribe component that the state has updated.

For example:
My current use case is slightly contrived and might not necessarily be the best way to solve the problem but it illustrates the problem with broadcast messages well.
I have a test harness app that allows new apps to be opened either in the root or in any nested iframe. This allows us to create deeply nested app hierarchies for testing messaging across boundaries. To open an app we broadcast a message on a public channel and the currently selected app then opens it (there are probably better ways of doing this as I said). Currently I need to add a special case:

this.publicChannel = await agaent.getOrCreateChannel("openWindowChannel");

this.publicChannel.addContextListener('openWindow', context => this.onOpenWindow(context));

public broadcastOpenWindow(): void {
    this.publicChannel.broadcast(targetAppIdentifier);

    if(this.selectedApp === this.appIdentity){
        this.onOpenWindow(targetAppIdentifier);
    }
}

Once again I'd like to state that if separate parts of the app do the subscribe and publish this would be much harder.

If we could optionally set the channel (and all context listeners) to broadcast back to the broadcast app we could simplify the code:

this.publicChannel = await agaent.getOrCreateChannel("openWindowChannel", { broadcastToSelf: true });

this.publicChannel.addContextListener('openWindow', context => this.onOpenWindow(context));

public broadcastOpenWindow(): void {
    this.publicChannel.broadcast(targetAppIdentifier);
}

This could work with both public and private channels but I am not too sure about how you would configure the user channels.

I imagine the signature would change to:

type ChannelConfig = {
    broadcastToSelf?: boolean
}

function getOrCreateChannel(channelId: string, params?: ChannleConfig)
@Roaders Roaders added the enhancement New feature or request label Oct 29, 2024
@Roaders Roaders changed the title Add additional parameters to addCOntextLIstener to allow broadcast to be received by app that makes the broadcast Add additional parameters to getOrCreateChannel to allow broadcast to be received by app that makes the broadcast Oct 29, 2024
@kriswest kriswest added the api FDC3 API Working Group label Oct 31, 2024
@kriswest
Copy link
Contributor

Hi @Roaders. I think this (receipt of your own broadcasts) would be best handled via #1250 so that the different parts of the apps are using different copies of the API. I realise we've bumped that to the 2.3 scope for now - but I think if we are going to go that way we'd prefer to avoid adding additional arguments to the API calls. There has long been a desire to limit changes to the Desktop Agent API and I suspect the proposed change would be opposed by other participants.

Perhaps you could solve this in your own apps (that have this issue) by wrapping the broadcast and addContextListener functions so that contexts passed to broadcast are also passed to the handler added via addContextListener directly?

If neither route offers a solution you're happy with we can raise this at a Standards Working Group meeting for discussion - it would also end up in the 2.3 scope.

@Roaders
Copy link
Contributor Author

Roaders commented Nov 21, 2024

Thanks for the reply @kriswest - I thought that I had already replied here but obviously not...

Using sub agents might resolve some of the issues but it may well raise others. I guess that these issues are probably more to do with the sub agent proposal than this proposal so I have added them on the other issue that you linked.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api FDC3 API Working Group enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants