- From: Joshua Peek <josh@joshpeek.com>
- Date: Mon, 23 Jun 2014 10:56:40 -0500
- To: Adam Barth <w3c@adambarth.com>
- Cc: WHATWG <whatwg@whatwg.org>
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 <w3c@adambarth.com> wrote: > On Mon, Jun 23, 2014 at 8:28 AM, Anne van Kesteren <annevk@annevk.nl> wrote: >> On Mon, Jun 23, 2014 at 5:11 PM, Adam Barth <w3c@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
Received on Monday, 23 June 2014 15:57:05 UTC