Fetch claims to define ReadableStream, but Streams is the actual location

[tabatkins]

Currently Fetch has a definition for ReadableStream, despite Streams having the actual definition. I suspect this predates use of Bikeshed, as it immediately has a biblio reference to Streams, and the "have a local definition but biblio-link to the real dfn's spec" was a common practice in The Bygone Days.

Can we remove this definition, or at least mark it as "local only" by giving it lt="" local-lt="ReadableStream"?

[ricea]

The Service Worker standard uses this definition of ReadableStream here: https://w3c.github.io/ServiceWorker/#cache-put (step 8.1). I think it could probably be migrated to use the streams standard for this one, although it still needs other stream-related definitions from the fetch standard.

[jakearchibald]

https://wicg.github.io/background-fetch/ uses these a lot, but mostly when I want to use spec-level streams.

…

On Mon, 30 Jul 2018, 03:00 Adam Rice, ***@***.***> wrote: The Service Worker standard uses this definition of ReadableStream here: https://w3c.github.io/ServiceWorker/#cache-put (step 8.1). I think it could probably be migrated to use the streams standard for this one, although it still needs other stream-related definitions from the fetch standard. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#780 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAFtmkxMzblB7BkK2UhnbPb-NadZVVXAks5uLmi0gaJpZM4Vkbo6> .

[annevk]

I thought Streams defined the JavaScript class, whereas Fetch defines the IDL "wrapper"? You can contrast this with JavaScript defining the Uint8Array class and IDL defining the IDL "wrapper" for it.

[tabatkins]

The problem here is that Bikeshed doesn't recognize the notion of a JS class definition distinct from an IDL definition; in other words, I don't have definition types for JS itself. But Streams is using the IDL dfn types, so they're colliding here.

Ultimately tho, I don't understand why Streams wants to define the JS and not the IDL. It has its own reasons for wanting to provide an actual pure-JS dfn, and that's fine, but not having the IDL either just seems weird, given that every spec that wants to interact with it is going to do so via IDL. Weird for another spec to define the IDL (and do so purely in prose, too, rather than with an IDL block...).

[ricea]

See whatwg/streams#45 for the long discussion of Streams vs. IDL.

and do so purely in prose, too, rather than with an IDL block...

It's worth noting that the WebIDL standard itself doesn't use IDL blocks to describe JS types.