Re: [whatwg/streams] Add URL.createObjectURL(stream) support (#480)

This is going to sound like hyperbole but it really isn't: this is probably the most important thing ReadableStream could do to advance the web platform.

Let me explain.

For quite a while now we've had alternative transports available in the browser (WebSockets & WebRTC data channel). With that we've built even higher order transports like WebTorrent to distribute content. I've also seen different tarball and other multi-file compression bundles used in these data channels as well as within the new fetch() API.

Today, the usefulness of these transports is hampered by the fact that they are locked out of a substantial portion of the web platform. The reason people are mostly sending application data rather than *actual content* is that you can't effectively use media elements with non-HTTP transports unless you can buffer all of the content up-front into a bundle that can be turned into a single Blob and then sent to createObjectURL().

I understand your perspective @domenic because you're thinking pretty directly in terms of the current implementations but at a purely technical level there is no difference between a ReadableStream and an HTTP network request in the terms you've outlined about (can be zero, can be undetermined length, etc).

I can't tell you the backflips I've gone through in the last six months that would be unnecessary if this feature were added. I've added ServiceWorkers in order to build an HTTP interface for streaming data, I've built HTTP servers into Electron apps to do the same, I've created entire micro-service infrastructures to "fake" live files being pushed over WebSockets. And all of these end in user experiences that are *much worse* that what would be very simple were this feature available.

Today, ReadableStreams aren't all that useful because there's a limited number of APIs that expose and consume them. The list of non-ReadableStream "streaming" interfaces in the browser is absurd: MediaStream, File API, RTCDataChannel, WebSocket, whatever the hell the Speech API creates, etc. If we were able to create object URLs from a ReadableStream we could start to build compatibility layers from these non-standard interfaces that could be used in other parts of the web platform that just need a URL. If we want ReadableStream to become more widely used a good strategy would be to make it the obvious compatibility layer between all of these incompatible APIs and anything that takes a URL.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/streams/issues/480#issuecomment-271110536