>It depends on to what extent these MSE APIs are shipping and thus >compatibility needs to be preserved.
MSE is in CR and there are shipping implementations. >I'd love to work with you or the editors on that I have added [email protected] to this thread. /paulc Sent from my Windows Phone ________________________________ From: Domenic Denicola Sent: 13/10/2014 3:04 PM To: Paul Cotton; Takeshi Yoshino Cc: public-webapps; Arthur Barstow; Feras Moussa Subject: RE: [streams-api] Seeking status of the Streams API spec From: Paul Cotton [mailto:[email protected]] > MSE [1] simply used the "Stream" object directly from the previous W3C WD > [2]. Since this object no longer is available in [3], what you do recommend > that MSE should do? OK, down to the fun stuff :). Here's my take based on some brief investigation... It depends on to what extent these MSE APIs are shipping and thus compatibility needs to be preserved. If they are shipping, something similar to appendStream seems OK: change it to take a ReadableStream and you'll be fine. However, BufferSource is basically a custom WritableStream instance, with many parallels I can outline if necessary. So ideally the related MSE APIs would be redesigned to either use a WritableStream directly, or to subclass it. That would be more idiomatic in how the streams ecosystem works, and in general would allow more compositional scenarios through the usual mechanisms (so that e.g. people could integrate the BufferSource writable stream into a generic stream pipeline, instead of special-casing how they handle it). I'd love to work with you or the editors on that, if there are no compat-constraints preventing it.
