Re: Splitting Stream into InputStream and OutputStream (was Re: CfC: publish WD of Streams API; deadline Nov 3)
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, public-webapps@w3.org
Hi François
On Thu, Oct 31, 2013 at 6:16 AM, François REMY francois.remy@outlook.com
wrote:
- 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.
Re: Splitting Stream into InputStream and OutputStream (was Re: CfC: publish WD of Streams API; deadline Nov 3)
On Thu, Oct 31, 2013 at 4:48 PM, François REMY
francois.remy@outlook.com wrote:
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:
Basically it should be sufficient if each API can check type, but yeah
probably useful.
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.
Interesting. Maybe also accept an array of strings?
Splitting Stream into InputStream and OutputStream (was Re: CfC: publish WD of Streams API; deadline Nov 3)
Hi François On Thu, Oct 31, 2013 at 6:16 AM, François REMY francois.remy@outlook.com wrote: - 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.
