-
Notifications
You must be signed in to change notification settings - Fork 106
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
New channel proposition #171
Changes from 3 commits
099930e
a72585a
12142f7
f190362
e793d25
ba3afdf
b4d4b94
6d6999a
3f8e09d
4c21494
2c5c753
ff3cde4
87d9473
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -166,15 +166,15 @@ The 'global' channel should be returned as part of the response from the `fdc3.g | |
An app gets the current context of the `global` as a fallback if no other context is set. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I am not sure what this means? Can you expand on what you mean by a fallback? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. some platforms may have a tiered approach, where there is a global context (maybe coming from a top-level search) and more localized contexts created with channels. In that case, if an app doesn't have a context coming from a specific channel it is joined to it may want to pull the global context. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I am tempted to say this is slightly inconsistent with the rest of the behaviour, and therefore introduces a bit of confusion. I think channels should always work the same way, regardless of what context it is. If you are on no channel, no context will be recorded. If you want context to be recorded, join a channel. In this particular case I would prefer if the spec doesn't mention this behaviour. Someone can still do this if they like, as the standard wouldn't explicitly forbade it, but I don't personally think it makes much sense. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I agree with @rikoe here. I feel we are kind of reintroducing a new special behavior for "global" with this wording. The way I expect - If I join There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @rikoe , @vmehtafds - some clarifications:
@rikoe I am not clear on the concerns (I don't see how this is going against channels always working the same) but I am fine changing this example to something else. Do you have any suggestions? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @nkolba I see what you mean now - adding an explicit listener to global. No other concerns with what you describe. However, The language here indicates special fallback behaviour without having to set up extra explicit listeners, which is unexpected. If you are joined to global, getCurrentContext should get you the context on global, if not, you will get nothing. I think it will be clearer if we just remove the word "fallback" everywhere. Of course you can still directly retrieve the channel itself and listen/retrieve the context on it, but that is a separate workflow from the join channel one. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @rikoe . Yes, if you are joined to There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Change If you want to make it even more clear: // retrieve current fdc3 context
const context = await fdc3.getCurrentContext("fdc3.instrument")
// context is null, as not currently joined to a channel
const globalChannel = await fdc3.getSystemChannels.filter(c => c.id === "global")
const globalContext = await fdc3.getCurrentContext("fdc3.instrument")
// context is instrument AAPL on the global channel
fdc3.joinChannel('global')
const context = await fdc3.getCurrentContext('fdc3.instrument')
// top-level context is now instrument AAPL as well because we have joined the global channel There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @rikoe just pushed some language cleanup There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @rikoe updated example pushed |
||
|
||
```js | ||
let gChan = await fdc3.getOrCreateChannel("global"); | ||
let ctx = await gChan.getCurrentContext("fdc3.instrument"); | ||
const globalChannel = await fdc3.getOrCreateChannel("global"); | ||
const context = await globalChannel.getCurrentContext("fdc3.instrument"); | ||
``` | ||
|
||
An app wants to respond to all context changes, whether on a joined channel or the `global` channel. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I also don't understand what is sentence mean and what feature/behavior the below example demonstrates. Can you just expand a bit? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @vmehtafds . This example is showing an app listening to the global channel outside of whatever channel it may be joined to. This example is meant to illustrate context scopes - i.e. I may have a joined channel scope and a global scope. For example, in a multi-windowed application, I may have a top-level search bar that represents global scope and individual windows may be on their own individual context scopes, or joined to a channel-wide context scope. This may or may not be useful for you. I am happy to get other examples in addition to or instead of this one. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I agree with @vmehtafds here: This is very confusing to me.
I think this idea of scoping etc. is unnecessary complexity at this stage and I don't believe it was something originally in the spec, or proposed before. We should just make channels mutually exclusive. If you do want this type of behaviour (which I think is unnecessary), it should be done by passing an array of channel names to join, and further API support for figuring out how channels are scoped/which "set" of channels you are in. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @rikoe @vmehtafds This example seems to be confusing and taking us down a rabbit hole. I'm happy to get other suggestions of how to illustrate the API. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Change There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @rikoe @vmehtafds - just pushed some clarifications to the language on this example. Please keep the feedback coming! |
||
|
||
```js | ||
let gChan = await fdc3.getOrCreateChannel("global"); | ||
let listener = gChan.addContextListener(contextListener); | ||
const globalChannel = await fdc3.getOrCreateChannel("global"); | ||
const listener = globalChannel.addContextListener(contextListener); | ||
``` | ||
|
||
### Direct Listening and Broadcast on Channels | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this now asynchronous?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suggested that based on the fact that
joinChannel
being asynchronous. It could be useful to know when the leave operation successfully completed (or not).There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@vmehtafds @nkolba I don't understand why this requires it to be asynchronous. success/error reporting is not the same thing as long-running operations that need to be asynchronous.
If you call the method without an exception, it worked. If it throws an exception, it didn't. If leaving (or joining) a channel as implemented in anything more then O(1) time, the implementation is doing something very weird.
I think making this operation asynchronous adds unnecessary complexity and ambiguity, and is a mistake.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@rikoe @vmehtafds . I'm in favor of keeping things simple.
Given that joinChannel is async - I was thinking symmetry and consistency (most other methods are async). However, there is definitely a good case to be made for keeping it sync.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is joinChannel async? 🤔 I would argue the same applies. I do agree that both join and leave should both be consistent though...
Arguably both join and leaving channels should be instant no-ops, but happy to go with the majority view here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I could see wanting to do this: