Re: [w3c/FileAPI] Streams is hot, FileReader.readAs____ is not (#40)

Regarding size, I think that is a somewhat orthogonal issue that can be solved separately. We could add .stream() ASAP, and later add .size if possible, or figure out some out-of-band way of passing through the size specific to whatever progression framework we come up with, or... For now, no Content-Length would get set.

I don't quite remember what purpose the to-stream-able protocol would serve. I guess maybe some internal protocol that produces a { readableStream, optionalLength } structure could be used to remove the switch statements in Fetch, but that's just spec-factoring.

@inexorabletash, I can prioritize working on this next week if you think the spec is ready to accept a PR. We're still figuring out how to interface streams with other specs nicely, so I think having me do the initial work for this spec would be nice. So, a few concrete questions:

- Is this spec ready to accept such a PR? Maybe we should get more implementer commitments first?
- What's the name? I like `.stream()`, but if we do `.arrayBuffer()` returning a promise for an array buffer, maybe it's confusing for `.stream()` to return a non-promise? Maybe that argues for `.toStream()` or `.asStream()`.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/FileAPI/issues/40#issuecomment-249873563