-
Notifications
You must be signed in to change notification settings - Fork 7
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
Large message considerations #11
Comments
This comment was marked as off-topic.
This comment was marked as off-topic.
Many thanks @backkem for your feedback and new created issues, we will integrate your comments when migrating this proposal to the WICG repo in Q4. Added you in the acknowledgements section. |
Merged
Considered closed by #23. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Since one of the screenshots indicates file dropping as a use-case, I wanted to highlight considerations for sending larger files. This was also a point of iteration for WebRTC (example).
One disadvantage of a
.send( string )
and.on("message", function )
approach is that you have to either send a file in one big chunk or implement your own chunking protocol. The former requires loading the entire file into memory which could become a bottleneck and the latter requires more work by the consumer of the API.One option that may be worth considering is to add an API inspired by WebTransport. There is an example attempt at doing this from the ORTC Community Group: p2p-webtransport. The spec doesn't have a motivation section but there is some background in w3c/webtransport#35. It would be nice if all transports (such as this proposal and WebRTC) shared this kind of API.
As a side node: the WebTransport API also has an option for unreliable streams that could be relevant to real-time (E.g. video or gaming) use-cases.
The text was updated successfully, but these errors were encountered: