Re: [whatwg] Fetch API: asHTML
On Mon, Jun 23, 2014 at 9:35 PM, Jonas Sicking jo...@sicking.cc wrote: Note that you can't do JSON decoding without first doing binary-text decoding. So by having a asJSON function we are automatically pulling in charset conversion. Yes, Domenic pointed that out. The same is true for asText(). But note that we're only using the utf-8 decoder. -- http://annevankesteren.nl/
Re: [whatwg] Fetch API: asHTML
On Sun, Jun 22, 2014 at 6:10 AM, Adam Barth w...@adambarth.com wrote: I haven't been following the fetch API in detail. Is there some collective understanding of what abstraction layer fetch represents? It's at the same level as XMLHttpRequest. For example, I could imagine that we might not want to add a dependency from the fetch to the HTML parser because fetch is a lower layer of the system. The API in question would be on the FetchBodyStream returned from the network. Adding asHTML there wouldn't pose any requirements on the underlying Fetch system. However, I think we should wait with adding more as* APIs until we have some experience with the current set of features. -- http://annevankesteren.nl/
Re: [whatwg] Fetch API: asHTML
Sounds good Anne. Its pretty easy to feature detect these capabilities now that they are normal methods. Patiently awaiting Streams itself to be finalized. Thanks! On Mon, Jun 23, 2014 at 5:15 AM, Anne van Kesteren ann...@annevk.nl wrote: On Sun, Jun 22, 2014 at 6:10 AM, Adam Barth w...@adambarth.com wrote: I haven't been following the fetch API in detail. Is there some collective understanding of what abstraction layer fetch represents? It's at the same level as XMLHttpRequest. For example, I could imagine that we might not want to add a dependency from the fetch to the HTML parser because fetch is a lower layer of the system. The API in question would be on the FetchBodyStream returned from the network. Adding asHTML there wouldn't pose any requirements on the underlying Fetch system. However, I think we should wait with adding more as* APIs until we have some experience with the current set of features. -- http://annevankesteren.nl/
Re: [whatwg] Fetch API: asHTML
On Mon, Jun 23, 2014 at 3:15 AM, Anne van Kesteren ann...@annevk.nl wrote: On Sun, Jun 22, 2014 at 6:10 AM, Adam Barth w...@adambarth.com wrote: I haven't been following the fetch API in detail. Is there some collective understanding of what abstraction layer fetch represents? It's at the same level as XMLHttpRequest. XMLHttpRequest isn't particularly cleanly layered. It's sounds like you're not overly concerned about layering, which is probably fine. Adam For example, I could imagine that we might not want to add a dependency from the fetch to the HTML parser because fetch is a lower layer of the system. The API in question would be on the FetchBodyStream returned from the network. Adding asHTML there wouldn't pose any requirements on the underlying Fetch system. However, I think we should wait with adding more as* APIs until we have some experience with the current set of features. -- http://annevankesteren.nl/
Re: [whatwg] Fetch API: asHTML
On Mon, Jun 23, 2014 at 5:11 PM, Adam Barth w...@adambarth.com wrote: XMLHttpRequest isn't particularly cleanly layered. It's sounds like you're not overly concerned about layering, which is probably fine. I think I see what you mean. If you wanted to implement this in terms of JavaScript then indeed you would end up importing several modules other than the fetch module to implement these methods. E.g. encoding, for asText, filesystem and MIME for asBlob, and encoding and JSON for asJSON. For asHTML you'd need encoding and HTML. This seems fine to me. However, I could see it instead has to go the other way around. Instead of having a bunch of methods on stream to convert it into various other pieces. Other pieces could have ways of dealing with streams. That might make coding a bit more awkward though. -- http://annevankesteren.nl/
Re: [whatwg] Fetch API: asHTML
From: annevankeste...@gmail.com annevankeste...@gmail.com on behalf of Anne van Kesteren ann...@annevk.nl However, I could see it instead has to go the other way around. Instead of having a bunch of methods on stream to convert it into various other pieces. Other pieces could have ways of dealing with streams. That might make coding a bit more awkward though. Right, this would be more pure I suppose. But IMO the usability gain here is worth the layering violations. .NET-style stream readers are not very fun to work with in my experience. It would be good to have a clear mental model guiding the API decisions though. For example, isolating the layering violations into the convenience asXYZ methods.
Re: [whatwg] Fetch API: asHTML
On Mon, Jun 23, 2014 at 8:28 AM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Jun 23, 2014 at 5:11 PM, Adam Barth w...@adambarth.com wrote: XMLHttpRequest isn't particularly cleanly layered. It's sounds like you're not overly concerned about layering, which is probably fine. I think I see what you mean. If you wanted to implement this in terms of JavaScript then indeed you would end up importing several modules other than the fetch module to implement these methods. E.g. encoding, for asText, filesystem and MIME for asBlob, and encoding and JSON for asJSON. For asHTML you'd need encoding and HTML. Yes, exactly. However, the sadness comes when the HTML module ends up depending on the fetch module because that creates a circular dependency. You then need to merge them into one module, which will quickly become the everything module. This seems fine to me. This discussion is about theoretical purity, which is pretty far down the list things we should care about. However, I could see it instead has to go the other way around. Instead of having a bunch of methods on stream to convert it into various other pieces. Other pieces could have ways of dealing with streams. That might make coding a bit more awkward though. It might be instructive to think about how the Node community would structure these APIs. Node has a much stronger notion of modules and dependencies than browsers because Node uses npm. As Node developer, I would be sad if my networking module dragged in an entire HTML implementation. Adam
Re: [whatwg] Fetch API: asHTML
From: Adam Barth w...@adambarth.com It might be instructive to think about how the Node community would structure these APIs. Node has a much stronger notion of modules and dependencies than browsers because Node uses npm. As Node developer, I would be sad if my networking module dragged in an entire HTML implementation. This is a great point. From this perspective, JSON is fine since it's part of the JS language. Encoding is a bit on the edge; it's a judgement call based on whether your networking module wants to recognize the fact that networks often transport text, or whether it should stay purely on the bytes level. The convenience argument pushes me toward saying encoding is OK, especially since that's a unidirectional dependency. But HTML is definitely out.
Re: [whatwg] Fetch API: asHTML
Thats a good point. You need a document context to do any sort of Element construction. Fetch shouldn't have any dependency on a document since its targeting ServiceWorkers. I'd say asHTML isn't going to work out. But document.parseHTMLStream(response.body) seems fine to me. A discussion for another thread. On Mon, Jun 23, 2014 at 10:41 AM, Adam Barth w...@adambarth.com wrote: On Mon, Jun 23, 2014 at 8:28 AM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Jun 23, 2014 at 5:11 PM, Adam Barth w...@adambarth.com wrote: XMLHttpRequest isn't particularly cleanly layered. It's sounds like you're not overly concerned about layering, which is probably fine. I think I see what you mean. If you wanted to implement this in terms of JavaScript then indeed you would end up importing several modules other than the fetch module to implement these methods. E.g. encoding, for asText, filesystem and MIME for asBlob, and encoding and JSON for asJSON. For asHTML you'd need encoding and HTML. Yes, exactly. However, the sadness comes when the HTML module ends up depending on the fetch module because that creates a circular dependency. You then need to merge them into one module, which will quickly become the everything module. This seems fine to me. This discussion is about theoretical purity, which is pretty far down the list things we should care about. However, I could see it instead has to go the other way around. Instead of having a bunch of methods on stream to convert it into various other pieces. Other pieces could have ways of dealing with streams. That might make coding a bit more awkward though. It might be instructive to think about how the Node community would structure these APIs. Node has a much stronger notion of modules and dependencies than browsers because Node uses npm. As Node developer, I would be sad if my networking module dragged in an entire HTML implementation. Adam
Re: [whatwg] Fetch API: asHTML
On Mon, Jun 23, 2014 at 8:46 AM, Domenic Denicola dome...@domenicdenicola.com wrote: It might be instructive to think about how the Node community would structure these APIs. Node has a much stronger notion of modules and dependencies than browsers because Node uses npm. As Node developer, I would be sad if my networking module dragged in an entire HTML implementation. This is a great point. From this perspective, JSON is fine since it's part of the JS language. Encoding is a bit on the edge; it's a judgement call based on whether your networking module wants to recognize the fact that networks often transport text, or whether it should stay purely on the bytes level. The convenience argument pushes me toward saying encoding is OK, especially since that's a unidirectional dependency. But HTML is definitely out. Note that you can't do JSON decoding without first doing binary-text decoding. So by having a asJSON function we are automatically pulling in charset conversion. I think I was one of the original proponents of adding json as a native type to XHR. I'm not sure that this was a good idea. Especially not now given that we are so close to having a real Stream primitive, and that we will surely need an API for piping a Stream into a JSON parser. That said, I don't care particularly strongly either way. / Jonas
Re: [whatwg] Fetch API: asHTML
I haven't been following the fetch API in detail. Is there some collective understanding of what abstraction layer fetch represents? For example, I could imagine that we might not want to add a dependency from the fetch to the HTML parser because fetch is a lower layer of the system. Adam On Fri, Jun 20, 2014 at 2:39 PM, Joshua Peek j...@joshpeek.com wrote: Hey Anne, love the direction of the Fetch API. I'm curious what you think of an asHTML extension to the FetchBodyStream? Parsing fragment HTML from XHRs is pretty typical. It could potential return a DocumentFragment or if it used some streaming HTML parser, it could emit the top level nodes as they were being parsed. Any reasons why its a terrible idea? Or just something thats a little to complex to tackle in the early states of Fetch? Thanks!
[whatwg] Fetch API: asHTML
Hey Anne, love the direction of the Fetch API. I'm curious what you think of an asHTML extension to the FetchBodyStream? Parsing fragment HTML from XHRs is pretty typical. It could potential return a DocumentFragment or if it used some streaming HTML parser, it could emit the top level nodes as they were being parsed. Any reasons why its a terrible idea? Or just something thats a little to complex to tackle in the early states of Fetch? Thanks!
