updated spec with more detailed explanation of the 'default' channel #168
Conversation
| The one exception is the `default` channel. Because apps are automatically added to the `default` channel, the message routing behavior is different in order to prevent poor user experiences from unexpected context behavior. The behavior for the `default` channel is: | ||
|
|
||
| - All broadcasts (`fdc3.broadcast` when the app is on default, or `default.broadcast`) update the `default` context | ||
| - `fdc3.addContextListener` will NOT receive context events when the app is joined to the `default` channel |
There was a problem hiding this comment.
I don't mind this, but it is kind of unexpected behaviour, so we should be really clear that this is the case, and discuss it with the API working group.
It is also different from how broadcast and addContextListener worked in version 1.0, so we should clarify that this is a breaking change, and consider making the version 2.0.0 instead of 1.1.0 to indicate this.
There was a problem hiding this comment.
Definitely this is significant and needs to be vetted by the WG. I'm OK with adding language calling out that this may be a breaking change for some (or event many) 1.0 implementations. However, I don't believe that this is a breaking change for the spec requiring a 2.x designation - since the 1.0 spec intentionally leaves this behavior open-ended.
There was a problem hiding this comment.
Consider an simple application on 1.0 without any UI/frame/functionality for channels and all it does it fdc3.broadcast and fdc3.addContextListener.
Can it move to 1.1 without changing code and work as expected? Based on the above, the app would stop receiving any context but it can still send context on default channel. Is that correct? That seems confusing.
I think the difference in behavior of fdc3.addContextListener and fdc3.broadcast around default channel is confuisng.
There was a problem hiding this comment.
All my apps have just following two calls in their code base:
fdc3.broadcast and fdc3.addContextListener. They know nothing about being in a channel or not (which I think is very important).
I have a frame around that does channel management.
My apps can be in that custom frame (where they get channels) or in regular DesktopAgent/Windows frame (where there is no channels).
If I am understanding it correctly, basically any platform that doesn't implement Channels API, is useless for interop purposes because they can send stuff but not receive.
| @@ -150,10 +150,36 @@ The 'system' channels include a 'default' channel which serves as the backwards | |||
| ### Joining Channels | |||
| 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 broadcast over it or not. | |||
| 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. | |||
| The `default` channel has special behavior that makes it different from other channels. See a detailed description [below](#default-channel-behavior). | |||
There was a problem hiding this comment.
The special behaviour of the default channel should also be documented clearly in the API documentation, not only in the spec, as people are more likely to read the docs than the whole spec.
The spec doesn't clarify if the default channel is returned by getSystemChannels?
There was a problem hiding this comment.
Agreed about updates to the API docs - will do.
Re: getSystemChannels - there is definitely a gap here. There are arguments either way - would be great to get the opinions of others who have already built or are using channel linking today.
There was a problem hiding this comment.
I only have one "language" comment below which seems to be causing some confusion.
I suppose this begs the question: why is the default channel special at all in the first place? Isn't this a case where "less is more"?
Implementors which want to treat the default channel specially (such as ignoring context updates or not taking the state upon joining) are free to do so.
| The one exception is the `default` channel. Because apps are automatically added to the `default` channel, the message routing behavior is different in order to prevent poor user experiences from unexpected context behavior. The behavior for the `default` channel is: | ||
|
|
||
| - All broadcasts (`fdc3.broadcast` when the app is on default, or `default.broadcast`) update the `default` context | ||
| - `fdc3.addContextListener` will NOT receive context events when the app is joined to the `default` channel |
There was a problem hiding this comment.
I think this line in particular needs clarification or rewording, mostly because the phrase "when the app is joined" itself is ambiguous. This can be interpreted as:
- Context listeners will not receive a context updated event at the moment the channel is joined
- Context listeners will not receive context updated events while the channel is joined
|
@vmehtafds @nicholasdgoodman @rikoe I've made a new PR here that takes a different approach to resolving these issue. Please you please review and add your feedback? thanks! |
addressing questions raised in #118