Yes, having the InputStream and OutputStream interfaces would be great, and the 
“Stream” class could inherit from both. The important thing is that an external 
API can return either a readable or a writable stream, depending on what make 
sense for it.

Since JavaScript does not provide a way to check if an object implements an 
interface, there should probably exist a way to check that from the API, like:

   var stream = InputStream(s) // returns “s” if it’s an input stream, convert 
is into a stream if possible, or return null

   if(stream) { … } else { … }

That’s a great way to convert a string into a stream, for example, in the case 
of an API that requires an InputStream and must integrate with older code that 
returns a String or a Blob.

De : Takeshi Yoshino
Envoyé : ‎jeudi‎ ‎31‎ ‎octobre‎ ‎2013 ‎04‎:‎45
À : François REMY
Cc : Arthur Barstow,

Hi François

On Thu, Oct 31, 2013 at 6:16 AM, François REMY <> 

- Streams should exist in at least two fashions: InputStream and OutputStream. 
Both of them serve different purposes and, while some stream may actually be 
both, this remains an exceptional behavior worth being noted. Finally, a 
"Stream" is not equal to a InMemoryStream as the constructor may seem to 
indicate. A stream is a much lower-level concept, which may actually have 
nothing to do with InMemory operations.

Yes. I initially thought it'll be clearer to split in/out interface. E.g. a 
Stream obtained from XHR to receive a response should not be writable. It's 
reasonable to make network-to-Stream transfer happen in background 
asynchronously to JavaScript, and then it doesn't make much sense to keep it 
writable from JavaScript.

It has a unified IDL now but I'm designing write side and read side 
independently. We could decouple it into two separate IDLs? concepts? if it 
make sense. Stream would inherit from both and provides a constructor.

Reply via email to