[whatwg] [Fetch] ambiguity problem?
Not wanting to start a giant bikeshed here but if you have a look at Jake's Service Worker Examples as an early use of fetch and streams, it seems clear that many developers would be surprised by behavior of not being about to refer back to the response body. I'd like to suggest that this is less a problem with service workers and more with the (current at least) unfamiliarity with the idea that body is a stream, and maybe a lack of recognizable way to tell the difference from native apis. It seems like this is always going to be the case with code using fetch, not unique to ServiceWorkers. I think that commonly as developers we are used to response being a string or an already parsed object or something, and since both will persist in the platform. As such, I'd like to pose the idea of changing the IDL in 5.4 Response Class To add the word stream. I think in this case, the extra characters aren't bad and the clarity outweighs the cost. As in: readonly attribute FetchBodyStream http://fetch.spec.whatwg.org/#fetchbodystream body http://fetch.spec.whatwg.org/#dom-request-bodyStream;
Re: [whatwg] [Fetch] ambiguity problem?
On Aug 12, 2014 9:07 AM, Brian Kardell bkard...@gmail.com wrote: Not wanting to start a giant bikeshed here but if you have a look at Jake's Service Worker Examples as an early use of fetch and streams, it seems clear that many developers would be surprised by behavior of not being about to refer back to the response body. I'd like to suggest that this is less a problem with service workers and more with the (current at least) unfamiliarity with the idea that body is a stream, and maybe a lack of recognizable way to tell the difference from native apis. It seems like this is always going to be the case with code using fetch, not unique to ServiceWorkers. I think that commonly as developers we are used to response being a string or an already parsed object or something, and since both will persist in the platform. As such, I'd like to pose the idea of changing the IDL in 5.4 Response Class To add the word stream. I think in this case, the extra characters aren't bad and the clarity outweighs the cost. As in: readonly attribute FetchBodyStream bodyStream; Whoops, missing link http://jakearchibald.com/2014/reading-responses/
Re: [whatwg] [Fetch] ambiguity problem?
On Tue, Aug 12, 2014 at 3:07 PM, Brian Kardell bkard...@gmail.com wrote: Not wanting to start a giant bikeshed here but if you have a look at Jake's Service Worker Examples as an early use of fetch and streams, it seems clear that many developers would be surprised by behavior of not being about to refer back to the response body. Why? XMLHttpRequest does the same thing. -- http://annevankesteren.nl/
Re: [whatwg] [Fetch] ambiguity problem?
On Aug 12, 2014 9:13 AM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Aug 12, 2014 at 3:07 PM, Brian Kardell bkard...@gmail.com wrote: Not wanting to start a giant bikeshed here but if you have a look at Jake's Service Worker Examples as an early use of fetch and streams, it seems clear that many developers would be surprised by behavior of not being about to refer back to the response body. Why? XMLHttpRequest does the same thing. -- http://annevankesteren.nl/ In what way? . response is a completely read DOMString or Object or whatever, not a Stream?
Re: [whatwg] [Fetch] ambiguity problem?
On Tue, Aug 12, 2014 at 4:40 PM, Brian Kardell bkard...@gmail.com wrote: In what way? . response is a completely read DOMString or Object or whatever, not a Stream? In that you cannot get back to the original response. You can only get it in one chosen variant. -- http://annevankesteren.nl/
Re: [whatwg] [Fetch] ambiguity problem?
On Aug 12, 2014 10:45 AM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Aug 12, 2014 at 4:40 PM, Brian Kardell bkard...@gmail.com wrote: In what way? . response is a completely read DOMString or Object or whatever, not a Stream? In that you cannot get back to the original response. You can only get it in one chosen variant. If I do console. log(o.responseText); console. log(o.responseText); The second one will be what? The response text or nada? Isn't the later more analogous to what we're taking about here when it's a stream? It feels like it's reaching for consistency but could explain how it works either way.. -- http://annevankesteren.nl/
Re: [whatwg] [Fetch] ambiguity problem?
On Tue, Aug 12, 2014 at 7:22 PM, Brian Kardell bkard...@gmail.com wrote: If I do console. log(o.responseText); console. log(o.responseText); The second one will be what? The response text or nada? Isn't the later more analogous to what we're taking about here when it's a stream? It feels like it's reaching for consistency but could explain how it works either way.. That we store it on XMLHttpRequest is somewhat buggy, but that you can only get either JSON or a string is in the right direction and what I meant. Now we have promises we no longer need to store a copy on an object, but can just return the value. If you do asText() we could store the result on the Response object so it would work for multiple invocations, but that seems silly. -- http://annevankesteren.nl/
Re: [whatwg] [Fetch] ambiguity problem?
From: whatwg whatwg-boun...@lists.whatwg.org on behalf of Brian Kardell bkard...@gmail.com console. log(o.responseText); console. log(o.responseText); This is why I've been advocating for asJSON() and friends to be verbs, not nouns, i.e. readAsJSON(). Showing how you take an action makes you think harder about whether the action will be repeatable or not. (To me, in the context of a stream or a response, read is not repeatable. But others have suggested consume as a verb that makes this clearer, for people who aren't as steeped in the semantics of those objects.)
Re: [whatwg] [Fetch] ambiguity problem?
On Aug 12, 2014 1:38 PM, Domenic Denicola dome...@domenicdenicola.com wrote: From: whatwg whatwg-boun...@lists.whatwg.org on behalf of Brian Kardell bkard...@gmail.com console. log(o.responseText); console. log(o.responseText); This is why I've been advocating for asJSON() and friends to be verbs, not nouns, i.e. readAsJSON(). Showing how you take an action makes you think harder about whether the action will be repeatable or not. (To me, in the context of a stream or a response, read is not repeatable. But others have suggested consume as a verb that makes this clearer, for people who aren't as steeped in the semantics of those objects.) Unless I'm misunderstanding though, (you'd certainly know) from Jake's description it sounds like it's the body stream that gets used up/requires cloning, which is why I suggested, just call it that. If that's wrong then readAs makes more sense to me. I agree that it determines how you reason about things.
