-
Notifications
You must be signed in to change notification settings - Fork 6
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
Introduce experimental real time channels #77
Closed
Closed
Changes from 15 commits
Commits
Show all changes
18 commits
Select commit
Hold shift + click to select a range
b66a9f1
add page
e72ac99
more docs
Septias 8636324
improve docs
Septias 18c9bf4
restructuring
Septias d9b0fb8
sna
hpk42 1b1443d
new draft of API after discussion with adz
hpk42 daff2c2
clarify
hpk42 a0dca14
some more precision in the API definition
hpk42 2874e93
revert back to send/setlistener api, no events anymore
hpk42 a83cfba
Update example
Septias e93b7db
Update example
Septias 646c2ed
try to finalize the api draft
hpk42 227c520
ominimize diff
hpk42 f9149ea
better formulation
hpk42 069fcaf
clarify network broken sentence
hpk42 7827b2c
remove left-over
hpk42 1047a63
fix typo
hpk42 42efb76
let both methods trigger the realtime participation
hpk42 File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,48 @@ | ||
# sendRealtimeData() | ||
|
||
```js | ||
window.webxdc.sendRealtimeData(data); | ||
``` | ||
|
||
**Note that this API is experimental and not fully settled (April 2024)** | ||
|
||
Send `Uint8Array` data to other realtime peers for this app. | ||
You must first call [`setRealtimeListener`](./setRealtimeListener.md) | ||
to announce participation in realtime data transmission. | ||
Note that any data sent before a first peer is connected might not arrive. | ||
It is up to the app to implement a "synchronization" protocol | ||
so that peers can detect each other presences. | ||
|
||
Any sent data is | ||
|
||
- **private to the chat**: Only chat members can receive realtime data. | ||
|
||
- **scoped to the app**: different apps in a | ||
chat can not discover or receive realtime data of other apps in the chat. | ||
|
||
- **ephemeral**: any sent data will only be received by the currently | ||
connected chat peers but not by peers joining later. | ||
There is no guarantee anyone is receiving the sent data | ||
because there might be no currently listening peers, | ||
or network connections broke. | ||
|
||
## Example | ||
|
||
```js | ||
let timeout | ||
hpk42 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
window.webxdc.setRealtimeListener((data) => { | ||
console.log("Received realtime data: ", data); | ||
const msg = new TextDecoder().decode(data); | ||
console.log("decoded message: ", msg); | ||
}) | ||
|
||
let pings = 0 | ||
setInterval(() => { | ||
const myId = window.webxdc.selfAddr; | ||
const data = new TextEncoder().encode(`[${pings}] hello from ${myId}`); | ||
pings += 1 | ||
console.log("Sending message", data); | ||
window.webxdc.sendRealtimeData(data); | ||
}, 1000) | ||
``` | ||
``` | ||
hpk42 marked this conversation as resolved.
Show resolved
Hide resolved
|
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,37 @@ | ||
# setRealtimeListener | ||
|
||
```js | ||
window.webxdc.setRealtimeListener((data) => {}); | ||
``` | ||
|
||
**Note that this API is experimental and not fully settled (April 2024)** | ||
|
||
Announce participation in realtime data sending and receiving to other peers. | ||
|
||
The `setRealtimeListener` callback receives `Uint8Array` data items | ||
that were sent from connected peers by [`sendRealtimeData(data)`](./sendRealtimeData.md). | ||
|
||
Calling `setRealtimeListener` with a `null` value | ||
will disconnect from receiving and sending realtime data. | ||
You may afterwards call `setRealtimeListener` again with a callback | ||
to re-establish participation in realtime sending and receiving. | ||
|
||
## Example | ||
|
||
```js | ||
let timeout | ||
window.webxdc.setRealtimeListener((data) => { | ||
console.log("Received realtime data: ", data); | ||
const msg = new TextDecoder().decode(data); | ||
console.log("decoded message: ", msg); | ||
}) | ||
|
||
let pings = 0 | ||
setInterval(() => { | ||
const myId = window.webxdc.selfAddr; | ||
const data = new TextEncoder().encode(`[${pings}] hello from ${myId}`); | ||
pings += 1 | ||
console.log("Sending message", data); | ||
window.webxdc.sendRealtimeData(data); | ||
}, 1000) | ||
``` |
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 don't know of any other web APIs that behave this way where an event listener has to be added first before any corresponding events can be emitted.
I can't think of any use-cases where you'd want to send but not listen for responses, but this seems like something that could be very frustrating for any devs that overlook this warning.
I assume the reason is that you'd like to avoid instantiating the ephemeral messaging stack unless it's required. Perhaps that stack could be launched on sending a message as well?
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.
good point -- i had thought about it but one iteration before the one you commented, we had
setRealtimeListener
return a promise that resolved only when a first peer is connected. So there was a way to do asendRealtimeData
after waiting for the promise to resolve and be optimistic that at least one peer will see it.Now, that we removed the promise, we could as well trigger the setup of the realtime machinery on
sendRealtimeData
as well even though it's almost guaranteed the sent data will not land anywhere if we are just starting the machinery. @link2xt what do you think? You were the most critical about the promise IIRC.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.
after some more thought, i addressed the comment and made the two methods symmetric in the sense that they both implicitely trigger the setup of realtime connections.
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 think there is no need to even specify when the stack is initialized. You can just call both methods whenever you want and API should do something meaningful, i.e. try to initialize the connection instead of dropping the message right away.
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.
if we keep connection setup totally implicit i wonder how would an app be able to ever force disconnection from peers? Ensuring that no code in an app still tries to send data may not be easy which would implicitely set it up again. I think it's better to have some explicit way to manage connectivity. If we also want to avoid having a dependency of top-level send and receive APIs then we should consider this API:
const realtimeSession = webxdc.joinRealtimeSession(receiveCallback)
and then having
realtimeSession.sendData()
andrealtimeSession.disconnect()
methods.There would be no way to send data or leave a session without first joining, and it's natural that after
disconnect
the session is invalidated and you need to start fresh to reconnect and send/receive data.This API design gives both explicit control over connectivity, and does not need a reminder to only send data after you registered a receive-listener.
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.
Here is my last comment implemented in a separate PR: https://github.com/webxdc/website/pull/78/files