Comments (15)
@vmehtafds the latest changes should address your concerns. The frame would use fdc3.joinChannel('red')
without the contained app knowing about it.
The app would only need to do fdc3.addContextListener(context => {})
.
The only caveat is that there is a default channel which matches the current 1.0 use case. Therefore fdc3.joinChannel('default')
will "reset" the channel, or turn broadcasting off.
So in your example you wouldn't have a distinction between "off" and "universal", you would just have "default". If you really want to turn it off completely, you could use fdc3.getOrCreateChannel('my_empty_channel')
and join that one to have no messages broadcast. But if no one broadcasts on the default channel, it would effectively be the same.
@nkolba @chedzoir @nicholasdgoodman does the above match your understanding? I don't have a problem with adding an explicitly built-in off
system channel, if it will help with this use case.
from fdc3.
As discussed briefly in the call today the question is whether it is the API's job or the implementer's to provide a way to mute/filter a channel to ensure that the channel is used or not.
The gut feel from folks on the call is that the channels API assumes that if a channel is being used, it is needed...so in your example above, you'd simply "detach" your title bar in this case from the channel when the GUI indicated the widget no longer should participate on a channel.
from fdc3.
This feels like an implementation feature.
Also, it seems that at least some of the issue is due to the ambiguity around the "default" channel. The purpose of the default is to provide backwards compatibility for the 1.0 broadcast/addContextListener apis. Maybe an approach would be to add a addChannelListener method that only listened to system channels (not default)? Another approach would be to extend addContextListener with an options arg that supported configuration of the listener. E.g.
fdc3.addContextListener(ctx =>{...}, {default:false});
from fdc3.
Any attaching/detaching of the listener requires the app code (which sets up the fdc3.addContextListener()
) to know that it inside a frame that supports channels.
My understanding was app doesn't need to know if the frame around it supports channels or not.
My simple analogy is to pipe with a tap dispensing water and a bucket to collect it. To me app just decides whether to have that bucket under the pipe to collect water or not. It doesn't decide whether water is running or at what speed. The bucket just know there is a pipe dispensing water. It doesn't even know about the existence of a tap.
The tap (analogous to the frame with channels) decides what speed the water flows (speed1=red-channel, speed2=green and so on) or if the tap is completely closed (off channel). The tap doesn't control if the bucket is there or not. It just adjust the water flow. That water could go in a bucket or just dropped on the floor.
Sorry if my example confused you even more 😄
I am sure there is a better analogy out there.
from fdc3.
I agree with you @rikoe and I know I could just make a dummy AppChannel and use that as off
(which I mentioned in my original comment)
My question was exactly the last question you raised in your comment - do we want to standardize it? Looks like at least you don't have any problem with that.
from fdc3.
Actually now that I think about it some more @vmehtafds, I don't think an off channel is the right solution at all. It is effectively a misuse of the FDC3 API to get the behaviour you want. If we create an official channel called "off", it would just be another system channel. Nothing would prevent apps from broadcasting to that channel or subscribing to it, which would be counter-intuitive. We would have to explicitly add a section to the spec creating this "special" channel that isn't a channel and that can't deliver events, even when they are sent (or a special exception to be thrown for this case).
I think the right solution is to have a boolean flag in your frame, shared with your contained apps, which can then be used to either unsubscribe when channels are turned off, or simply ignore any events while the flag is set. This will also be much more explicit to maintainers what is going on.
I.e. the right way not to listen to channels, is not to be subscribed to them!
If you really want to "hijack" channels to offer this functionality, you still have the option of creating a custom off channel with a name no one knows about, thereby achieving your aim of not having any events, without imposing the burden of additional logic on the standard and its implementers.
@nkolba @chedzoir @nicholasdgoodman @pjbroadbent any thoughts?
from fdc3.
@rikoe - I was trying to figure out an appetite for off functionality in the standard (as we have something like that in FactSet Workstation and is useful). If no one else needs the off functionality then it doesnt make sense to add it to standard.
I agree off
channel seems counter-intuitive. The other approach would be to add a new API to Channel for stopping/resuming (channel.stop()
and channel.resume()
). I dont want to complicate the standard/API if no one else sees a need for the "off" functionality.
from fdc3.
@vmehtafds I was actually thinking similar thoughts. I don't mind a channel suspension feature, I think, I would just wonder about giving one application power to stop interaction for all others.
Also, based on your image above we would need such a feature for all channels, or am I understanding wrong?
Otherwise you would have to go fdc3.getSystemChannels().find(c => c.id === 'default').stop()
?
from fdc3.
@rikoe - I would imagine that the suspension would be only for the app calling it and not for every app.
The more I am also thinking about it now, I feel I want fdc3.leaveCurrentChannel()
or something i.e. I should be able to say I am not in any channel and thus don't route any traffic to me.
Currently only way to leave a channel is to join another channel so there is no way to be not in any channel.
from fdc3.
You can! listener.unsubscribe()
😉
from fdc3.
@rikoe - Not really sure I understand. Is there a way for the frame to get the current listener?
The app which does fdc3.addContextListener()
would have access to the listener(as the return argument). But not sure how the frame would get that listener object easily. I might be missing something obvious.
from fdc3.
@vmehtafds TLDR: lengthy explanation is below, overall I'd recommend either implementing an "off" channel at the system level or changing the behavior of the "default" channel to not broadcast. Depending on how your titlebar is implemented, you may be able to polyfill this behavior from the titlebar without requiring the app to be aware of the plumbing.
...
The 1.0 spec is intentionally vague about the behavior of context routing in the broadcast API. The spec states the following:
On the financial desktop, applications often want to broadcast context to any number of applications. Context sharing needs to support concepts of different groupings of applications as well as data privacy concerns. Each Desktop Agent will have its own rules for supporting these features.
(https://fdc3.finos.org/docs/1.0/api/api-spec#send-broadcast-context)
And that broadcast Publishes context to other apps on the desktop.
(https://fdc3.finos.org/docs/1.0/api/DesktopAgent#broadcast)
And that addContextListener Adds a listener for incoming context broadcast from the Desktop Agent.
(https://fdc3.finos.org/docs/1.0/api/DesktopAgent#addcontextlistener)
The intention was to give desktop agents wide latitude in implementing business logic around how context is routed between apps. In 1.0 there is no contract guaranteeing delivery of a broadcast.
The addition of the channels APIs in 1.1 formalizes the implementation - so that there is now a contract for channels. From the 1.1 spec:
Apps can join channels. An app can only be joined to one channel at a time. When an app joins a channel it will automatically recieve the current context for that channel, except if the channel joined is the 'default'. When an app is joined to a channel, calls to fdc3.broadcast and listeners added through fdc3.addContextListener will be routed to that channel. If an app is not explicitly joined to a channel, it is on the 'default' channel. It is up to the desktop agent to determine the behavior of the 'default' channel, and if context is automaticaly[sic] broadcast over it or not.
(https://fdc3.finos.org/docs/next/api/api-spec#joining-channels)
Note that this contract quite explicitly is not binding for the default channel.
The expectation here is that if you are using SystemChannels to link app context sharing, the end user is only going to want apps sharing context if they have explicitly linked them through a color scheme or some other grouping like a workspace. However, this effectively means that the “default” channel becomes for all intents and purposes an “off’ channel for apps relying on fdc3.broadcast and fdc3.addContextListener. For these apps, the transition to the channels approach would constitute a breaking change. Note that if we instead had a “leaveChannel” api, we’d have the exact same problem with backwards compatibility/ Desktop agents would have to choose whether not being in a channel meant broadcast is a no-op (and potentially break 1.0 expectations) or if broadcast just routed globally if you weren’t in a channel (once again, requiring a “really off” state).
The expectation of the above part of the spec is that desktop agents making that transition are best positioned to make the rules about the default channel that make the most sense for them - especially since desktop agents are free to create what system channels they want and what rules they want around them. So, the desktop agent could have the default channel always broadcast and add its own “off” system channel.
To sum up:
- The “default” channel is the state of an app when it is not joined to channel
- Desktop Agents are required to route broadcast context on joined channels and to provide the current context when an app joins a channel for all channels except the “default"
- It is up to the desktop agent to decide what the behavior of the “default” is an manage backwards compatibility with the pre-channels world of 1.0
- Allowing an end user to remove an app from receiving broadcasts is a feature of a desktop agent - this could be the behavior of the “default” channel, or the desktop agent could expose a different “off” channel that would not route broadcasts
from fdc3.
@vmehtafds - after some more discussions with @rikoe , I've made a proposed update to the spec, which you can see in #168.
The proposed behavior for the 'default' would have it effectively behave as an 'off' channel, those apps could opt-in to explicitly listen to its context if they wanted to. Your feedback on the PR would be very helpful!
from fdc3.
@vmehtafds @rikoe Reference implementation @ https://github.com/nkolba/desktop-agent is now updated to work this way, if you want to see it in action.
from fdc3.
Addressed with PR #171
from fdc3.
Related Issues (20)
- Another Duplicate Name HOT 2
- Add property to support analytics across apps HOT 3
- Standardize the representation of currency pairs by fdc3.instrument HOT 8
- Standard WG Meeting - July 25th, 2024 HOT 10
- Adding Event Listeners on Private Channel HOT 1
- Inconsistent Use of Promises HOT 4
- Bug or Inconsistency? HOT 1
- Question: AddContextListenerResponsePayload does not contain channelId HOT 2
- FDC3 monorepo HOT 2
- Use Cases and Workflows Discussion Group - 1st August 2024 HOT 5
- Make Listener.unsubscribe() async for consistency HOT 7
- Simplify Web Connection Protocol HOT 7
- IFramePositioning HOT 2
- RaiseIntentResultResponse HOT 3
- Question: resolvers / channel selectors UI HOT 5
- Spelling Error: FindIntentsByContextsResponse HOT 1
- broadcastEvent on no channel
- Adding Channel State For JoinUserChannel / AddContextListener
- Question: IntentEvent has no targetApp property HOT 1
- Question: How does DesktopAgentProxy remove event listener?
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from fdc3.