- From: Domenic Denicola <notifications@github.com>
- Date: Tue, 27 Sep 2016 07:01:08 -0700
- To: w3c/FileAPI <FileAPI@noreply.github.com>
- Message-ID: <w3c/FileAPI/issues/40/249873563@github.com>
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
Received on Tuesday, 27 September 2016 14:12:04 UTC