| 05:00 | <zcorpan> | Hixie: can you pls regen? kthxbye :-) |
| 05:31 | <Hixie> | zcorpan: i tried, but got assertion errors in anolis since i was still set to using html5lib |
| 05:31 | <Hixie> | zcorpan: will try again tomorrow |
| 07:19 | <Ms2ger> | gsnedders, way to spam me :) |
| 07:36 | <annevk> | mounir: heh, sure, this 70% is better quality too, Lindt is okay |
| 08:14 | <annevk> | Heh, why did I not see http://dev.w3.org/html5/decision-policy/html5-2014-plan.html until now |
| 08:15 | <annevk> | I love how first it says "monolithic kitchen sink specification" (without acknowledging that is a WHATWG graphic and that the situation at the W3C is different) and then goes on to claim "HTML5 is good at modularity" as if they didn't just say monolithic |
| 08:31 | <jgraham> | gsnedders: I doubt I can either. |
| 08:32 | <jgraham> | Which review is this? |
| 08:50 | <darobin> | annevk: I won't necessarily defend "plan 2014", certainly not to the letter, but in fairness the link to the image is straight to http://images.whatwg.org/abstract.png which, well, doesn't exactly hide the provenance :) |
| 08:51 | <darobin> | also, it is entirely possible to believe that a specification is handled in a monolithic manner but that the technology lends itself to (some forms of) modularity |
| 08:54 | <annevk> | (my point was mostly that WHATWG HTML is larger than W3C HTML5; so that using that graphic as representing W3C HTML5 is weird, especially with the weird Jeff Jaffe modular dance it is followed with) |
| 08:55 | <darobin> | annevk: yeah, I won't dispute that there's weirdness |
| 09:11 | <jgraham> | What's the best URL to use as a reference for web-platform-tests? |
| 09:12 | <annevk> | https://github.com/w3c/web-platform-tests |
| 09:13 | <jgraham> | Not really that useful as an introduction to what wpt *is* |
| 09:15 | <darobin> | jgraham: depends on what level of introduction — perhaps the README should be pimped to serve the purpose you have in mind? |
| 09:17 | <annevk> | krit: is there anything left we need to work on? |
| 09:17 | <jgraham> | darobin: Yeah, perhaps that's the right solution. It just means the answer to my original question depends on me actually creating such an introduction |
| 09:19 | <darobin> | jgraham: I think it may be useful, nothing obvious jumps at me from the TestTWF docs |
| 10:17 | <annevk> | darobin: that email broke threading again |
| 10:18 | <annevk> | Though it did not on http://lists.w3.org/Archives/Public/www-svg/2014Jun/thread.html |
| 10:18 | <annevk> | Gmail :/ |
| 10:18 | <darobin> | that's what I was going to say |
| 10:18 | <darobin> | I think the problem is at your end |
| 10:19 | <darobin> | the message has all the right Reply-To stuff |
| 10:19 | <annevk> | I guess Gmail sorts on Subject? |
| 10:20 | <darobin> | Thunderbird is a clusterfuck of brokenness on small trivial things like not corrupting mailboxes or not breaking its own UI every other minute; but you can be sure it got mailing list headers right |
| 10:20 | <darobin> | I have no idea, I always found GMail completely unusable |
| 10:22 | <annevk> | I find it super awesome, except for plain text and I guess the header stuff |
| 10:22 | <annevk> | Opera Mail was really great at those things, was hard to switch away from that |
| 10:25 | <darobin> | I never got to try Opera Mail because it crashed importing my email every single time I decided to give it a shot |
| 10:27 | <jgraham> | Wow the one thing that you can't accuse Thunderbird of is updating the UI too often |
| 10:27 | <jgraham> | It's changed like once in about 5 years |
| 10:30 | <gsnedders> | One thing you can't accuse Opera Mail of is changing, like, ever. |
| 10:35 | <darobin> | jgraham: I didn't accuse it of updating — but it (dynamically) breaks an awful lot |
| 10:35 | <jgraham> | Oh, I see |
| 10:35 | <Ms2ger> | I haven't had that experience |
| 10:36 | <jgraham> | I don't really rembmer that happening recently |
| 10:36 | <darobin> | just this morning I undeleted a mail in a thread, it made it show the thread twice in the box view, with one copy gradually losing its subject (and showing Jan 1970 for the date) as I deleted from the other |
| 10:36 | <darobin> | then it became impossible to delete the ghost thread |
| 10:36 | <darobin> | just another day with Thunderbird :) |
| 10:37 | <jgraham> | You might be using more advanced features than me :) |
| 10:38 | <darobin> | jgraham: it's true that figuring out how to enabling threading required pretty advanced experimental sleuthing |
| 10:38 | <darobin> | *enable |
| 10:42 | <Ms2ger> | I guess I never delete emails :) |
| 10:42 | <jgraham> | Yeah that's a point. I only delete spam |
| 10:43 | <gsnedders> | What kinda of weirdo deletes emails? |
| 10:43 | <gsnedders> | Oh, wait, darobin. |
| 10:47 | <jgraham> | evidently |
| 10:48 | <jgraham> | Which incidentially sounds like his album of terrible MOR music aimed at middle aged women "darobin: evidently" |
| 11:02 | <darobin> | ow, that's just mean jgraham :) |
| 11:04 | <darobin> | I guess it's the kind of music you could listen to while reading http://www.amazon.co.uk/The-Darobin-Legend-Mysterious-Warriors/dp/059529832X |
| 11:06 | MikeSmith | edits the Plan 2014 doc to add a link to http://ecx.images-amazon.com/images/I/513JXR8S50L._.jpg |
| 11:07 | <darobin> | haha |
| 13:14 | <annevk> | JakeA: Domenic: I've been looking into defining progress events better and something occurred to me. Streams will not help with actually identifying how many bytes transfered |
| 13:15 | <annevk> | JakeA: Domenic: HTTP network and cache fetch layer deals with content encodings and as such those details never make it all the way through |
| 13:17 | <JakeA> | annevk: hmm, so we need bytesReceived and bytesExpected on response.body? |
| 13:20 | <annevk> | JakeA: I'm not sure what the best solution is |
| 13:22 | <JakeA> | annevk: will there be the same issue reading from disk, or is this unique to web requests? |
| 13:22 | <JakeA> | annevk: bah, gotta go flight mode, for a flight no less |
| 13:23 | <annevk> | JakeA: I think this is unique to HTTP |
| 13:23 | <annevk> | JakeA: although it depends a bit on how we deal with zipped storage and such I guess |
| 13:23 | <annevk> | JakeA: we haven't really started exploring those details until recently |
| 13:24 | <annevk> | JakeA: safe travels |
| 13:24 | <annevk> | JakeA: I'm away starting second week of July |
| 13:49 | hemanth | is searching for some serious use-cases for generators |
| 13:52 | <hemanth> | Domenic, I would be very useful if you could suggest me few use-case studies of generators :-) |
| 13:54 | <Ms2ger> | You could perhaps look at https://mxr.mozilla.org/mozilla-central/ |
| 13:57 | <darobin> | I guess there's a reason they say "Helpful as a Ms2ger" |
| 13:57 | <hemanth> | Ms2ger, nice, the first thing I came across searching there was TODO: Bug 948484 - support arrow functions and ES6 generators :) |
| 13:57 | <zewt> | typically to make non-linear code linear, in my experience |
| 13:58 | <zewt> | similar to workers, i suppose |
| 13:59 | <Ms2ger> | darobin, so it's not only in my dreams they say that? |
| 13:59 | <hemanth> | I understand the power of yield |
| 13:59 | <hemanth> | Did some tree traversal with it as well, http://h3manth.com/new/blog/2014/tree-traversal-with-es6-generator/ |
| 13:59 | <jgraham> | You use them anytime you want lazy iteration |
| 14:00 | <jgraham> | Which is pretty often in my experience |
| 14:00 | <zewt> | jgraham: i find that to be a nice bonus, but not the main benefit |
| 14:00 | <hemanth> | Control flow w/suspend and resume |
| 14:00 | <zewt> | at least in my use in python |
| 14:01 | <hemanth> | something like var responses = yield [_get("index.html", resume()) is fun |
| 14:01 | <hemanth> | more like what koa and co does |
| 14:05 | <jgraham> | zewt: Are you talking about yield on the rhs? |
| 14:06 | <jgraham> | like foo = (yield bar()) |
| 14:06 | <jgraham> | I don't think of that as a generator, although the PEP does call it "extended generators" |
| 14:07 | <zewt> | jgraham: no, the generator itself |
| 14:08 | <jgraham> | So I don't exactly see how you are using them to make non-linear code linear that doens't amount to iteration |
| 14:08 | <zewt> | the main benefit i find is being able to write the generator itself linearly, eg. as if it's the top-level function and it's calling a function to output values, rather than having to save state and be called independently several times |
| 14:09 | <jgraham> | Right, the implicit state saving is useful |
| 14:09 | <hemanth> | it's ideal to encode infinite sequences and operations over them |
| 14:09 | <jgraham> | Rather than having to write a class |
| 14:09 | <zewt> | it's a bigger benefit than the streaming itself, IMO |
| 14:43 | <Hixie> | jgraham: you got a sec for debugging anolis/pms? |
| 14:48 | <jgraham> | Hixie: Perhaps |
| 14:49 | <Hixie> | i'm hitting the assert isinstance(buffer,bytes) on line 535 of inputstream.py (detectEncodingMeta) |
| 14:50 | <Domenic> | annevk: why do streams not help with that? |
| 14:50 | <jgraham> | Hixie: What are you doing to hit it? |
| 14:51 | <Hixie> | jgraham: http://anolis.hoppipolla.co.uk/aquarium.py/output?uri=http://www.whatwg.org/specs/web-apps/current-work/source-whatwg-complete&process_toc=on&process_xref=on&process_sub=on&w3c_compat_xref_a_placement=on&w3c_compat_xref_elements=on&parser=html5lib&serializer=html5lib&omit_optional_tags=on&output_encoding=ascii |
| 14:56 | <jgraham> | Hixie: Well you are evidently getting punted down the "not unicode" codepath, but at some point getting unicode data |
| 14:56 | <jgraham> | I'm not sure why |
| 14:57 | <jgraham> | s/not unicode/raw bytes/ |
| 14:57 | <Hixie> | i'm trying to use html5lib so i have a sane output that i can try to duplicate |
| 14:57 | <Hixie> | so in theory this will be the last time i need this |
| 14:57 | <Hixie> | so if you want to just band-aid it for now that's fine by me |
| 14:58 | <Hixie> | (the libxml.html + aaalib output that i was using before is not sane, especially with respect to whitespace) |
| 14:58 | <annevk> | Domenic: you could explain this as the network stream handing you a transformed stream without giving you access to the actual network bits |
| 14:58 | <Hixie> | oh, that reminds me |
| 14:58 | <jgraham> | Hixie: Well there is a real bug, probably in html5lib |
| 14:58 | <jgraham> | Somewhere around the code that SimonSapin changed to avoid a real bug in python |
| 14:58 | <Hixie> | annevk: i was talking to some folk at google the other day who do back-end html serving stuff, and they asked about a feature of service workers and i didn't know the answer |
| 14:59 | <Domenic> | annevk: yeah, i guess. but the transform stream could contain an accumulator that counts bytes transformed so far |
| 14:59 | <Hixie> | annevk: is there any way in service workers to batch requests? e.g. if the browser knows that it suddenly needs three scripts, can the service worker package them up into one back-end request and then split up the result? |
| 15:00 | <annevk> | Domenic: yeah, what JakeA was suggesting might work |
| 15:00 | <Domenic> | annevk: oh this is about progress events on service workers, not on XHR |
| 15:00 | <annevk> | Hixie: since you can do event.respondWith(promise), yes |
| 15:01 | <annevk> | Domenic: progress "events" for fetch() |
| 15:01 | <Domenic> | right |
| 15:01 | <Hixie> | annevk: how would you do the buffering? just set a timer for 1ms and see if you get any other requests in the meantime? or would the three requests be delivered to the worker at once? |
| 15:01 | <Domenic> | so RequestBodyStream should just be a stream of arraybuffers |
| 15:01 | <annevk> | Domenic: we recently figured out how exactly we wanted progress events for XMLHttpRequest to behave, while trying to figure out a plan as to how to write that in the specification I realized our streams approach is not quite ideal for that |
| 15:02 | <Domenic> | that's as close to "raw network bytes" as JavaScript gets |
| 15:02 | <annevk> | Domenic: no, Content-Encoding is already done at that point |
| 15:02 | <Domenic> | annevk: it shouldn't be. |
| 15:02 | <annevk> | Hixie: yeah I guess |
| 15:02 | <annevk> | Domenic: euhm |
| 15:02 | <Hixie> | annevk: would be nice if there was a less hacky way to know that a batch of requests came in at once |
| 15:03 | <Domenic> | annevk: RequestBodyStream should be raw bytes. If you want to decode, do `.pipeThrough(new TextDecoderTransform(request.headers["Content-Encoding"]))` |
| 15:03 | <Domenic> | s/["Content-Encoding"]/.get("Content-Encoding") |
| 15:03 | <annevk> | Hixie: how would you know such a thing? |
| 15:04 | <Hixie> | annevk: e.g. when i have the dependency thing i'm working on, and script A depends on scripts B, C, and D, and you tell the browser "i need script A!". The browser synchronously knows it needs A, B, C, and D. |
| 15:05 | <Hixie> | annevk: or similar for ES modules |
| 15:05 | <annevk> | Domenic: hmm, that would make fetch() noticeably harder to work with |
| 15:05 | <annevk> | Hixie: https://github.com/slightlyoff/ServiceWorker/issues/new ? |
| 15:08 | <Domenic> | annevk: add .asStringStream() then |
| 15:08 | <annevk> | Domenic: Content-Encoding has nothing to do with that |
| 15:08 | <Domenic> | annevk: then I don't understand; you said "Content-Encoding is already done at that point" |
| 15:09 | <Domenic> | oh dear |
| 15:09 | <annevk> | Domenic: browsers have a network & cache layer |
| 15:09 | <Domenic> | I'm getting Content-Encoding and text encoding mixed up |
| 15:09 | <annevk> | Domenic: that sits below the fetching layer |
| 15:09 | <annevk> | Domenic: which sits below the content layer |
| 15:09 | <Domenic> | so we're not exposing primitives to allow access to the raw, gzipped bytes? |
| 15:09 | <annevk> | Domenic: the network & cache layer deals with gzip and friends |
| 15:09 | <Domenic> | i thought that was the entire point of fetch having a stream API |
| 15:10 | <Domenic> | so if someone wants to fetch something and then store it on disk, you're going to un-gzip it first, then make them gzip it back to store efficiently on disk? |
| 15:11 | <annevk> | Domenic: I don't know, all I know is what we've explained so far |
| 15:11 | <Domenic> | annevk: I thought fetch was going to be a low-level API like Node's http.get |
| 15:11 | <Domenic> | or rather http.request |
| 15:11 | <annevk> | I'm not necessarily opposed to changing it, but that would require a bunch of coordination |
| 15:12 | <Domenic> | well does any of this impact near-term stuff? it seems all related to the eventual stream manifestation |
| 15:12 | <annevk> | Well, it seems it would affect whether you get a JSON object back or a failure because it was zipped |
| 15:12 | <jgraham> | Hixie: So I think upgrading html5lib has helped. I also think it's going to time out before you get a response… |
| 15:12 | <jgraham> | Oh, no, it worked |
| 15:13 | <Domenic> | nah, I figure asXXX can contain as many steps as you want, for maximum convenience |
| 15:13 | <annevk> | Domenic: whoa whoa whoa |
| 15:14 | <jgraham> | annevk doing his best Keanu Reeves impression there |
| 15:14 | <Domenic> | asJSON = is application/json? ok proceed; otherwise fail. is gzipped? pass through ungzip transform. now json parse. succeed? return object. fail ? return parse error |
| 15:14 | <Domenic> | i guess there's a text-decoding step there too |
| 15:14 | <Domenic> | after the ungzip |
| 15:15 | <Hixie> | jgraham: cool, let me try regenning... |
| 15:17 | <annevk> | Domenic: there is |
| 15:17 | <Hixie> | jgraham: thanks, looks like it worked! |
| 15:18 | <annevk> | Domenic: https://github.com/slightlyoff/ServiceWorker/issues/339 |
| 15:18 | <jgraham> | Hixie: Great |
| 15:18 | <Domenic> | annevk: indeed. and if you're doing transforms from array buffers to text to object, makes sense to me to make that compressed array buffers to uncompressed ones to text to object |
| 15:19 | <Hixie> | man, what a diff |
| 15:19 | <JonathanNeal> | SteveF: re <h>, would it be better for me to file a pull request with my polyfill or to create a separate polyfill repo? |
| 15:19 | <annevk> | Domenic: maybe, though it also quite fundamentally impacts what is going on today |
| 15:19 | <SimonSapin> | jgraham: Do you mean https://github.com/html5lib/html5lib-python/issues/127 ? This was worked around in html5lib |
| 15:20 | <jgraham> | SimonSapin: I don't think it was actually that bug, but it must have been something we fixed relatively recently |
| 15:20 | <SteveF> | JonathanNeal: i think the discussion has a little way to go on it yet, I would hold off if you are interested in it being used |
| 15:21 | <SteveF> | JonathanNeal: have been busy with other things but plan to make further contribution to dicussion |
| 15:26 | <JonathanNeal> | SteveF: got it, thanks! |
| 15:26 | <Domenic> | annevk: I don't think it impacts any APIs fetch exposes today. |
| 15:27 | <Domenic> | annevk: and I think if we don't provide this level of access now, we'll have to do more archaeology and discover what's underneath fetch to enable certain use cases. |
| 15:29 | <Hixie> | annevk: https://github.com/slightlyoff/ServiceWorker/issues/340 |
| 15:30 | <slightlyoff> | WAT |
| 15:31 | <slightlyoff> | I don't even...really? This can't be our bottleneck |
| 15:31 | <annevk> | slightlyoff: what are you talking about? |
| 15:31 | <slightlyoff> | We need advisory memory caching headers *long* before this |
| 15:32 | <slightlyoff> | #340 |
| 15:32 | <Hixie> | i'm not making any assertions about prioritisation |
| 15:33 | <slightlyoff> | Do we have data to suggest we need it? |
| 15:33 | <slightlyoff> | Do browser caches work this way WRT IPC latency elimination today? (Chrome doesn't) |
| 15:33 | <Hixie> | i'm not sure what you're asking |
| 15:34 | <Hixie> | what would this have to do with caches? |
| 19:49 | <caitp> | so, I'm curious --- what is the new Request object referenced in the fetch spec supposed to offer over existing XHR? |
| 19:50 | <TabAtkins> | A sane, simple API. |
| 19:50 | <TabAtkins> | Versus the several lines of crap you have to remember and type out with every XHR today. |
| 19:51 | <caitp> | well that would be lovely, but we'll see |
| 19:51 | <caitp> | it doesn't look like anyone has begun implementing it yet though |
| 19:52 | <TabAtkins> | No, it's quite new. |
| 20:01 | <caitp> | yeah, I need to take another look at it---but really the question here is like, taking jQuery for example, if they're already abstracting XHR, do they gain anything from eventually also abstracting Request |
| 20:02 | <caitp> | I guess nobody knows for sure until implementations exist |
| 20:03 | <Domenic> | it also seems like it will expose more potential capabilities |
| 20:03 | <Domenic> | especially once it becomes streaming |
| 20:07 | <TabAtkins> | caitp: "Will the libraries switch to it" isn't really a useful argument; libraries can paper over *lots* of things. Removing the necessity for libraries to exist for common pieces of the platform to be usable is important for the evolution of the platform. |
| 20:07 | <TabAtkins> | But also, yes, we'll be adding fun new things to Request over time. |
| 20:08 | <caitp> | well, I work on some of these libraries, so the question becomes "should we worry about adding support for Request once it's available --- what's the testability story like, etc" |
| 20:17 | <Domenic> | well Angular is just going to overwrite everything to make it "more testable" anyway, so I'm not sure why you're worried ;) |
| 20:17 | <Domenic> | TabAtkins: anything we can do about moving Status before TOC? I don't care that much, but would be nice. |
| 20:18 | <TabAtkins> | Domenic: Yes, planning on doing something about that, so you can supply a *local* version of some boilerplate and have it sub in instead. |
| 20:18 | <Domenic> | TabAtkins: Awesome! Will merge for now then. |
| 20:20 | <caitp> | it's not clear that we actually can "overwrite everything" when it comes to native code which uses native promises, since they might not respect our mocks :) |
| 22:52 | <gsnedders> | is it possible for Fetch to be polyfilled using XHR? |
| 22:54 | <caitp> | regarding what was being said earlier about extended possibilities (eg the Stream API), there's a bug open (or closed, I can't remember I didn't read it) about adding support for the stream api to xhr too |
| 22:54 | <caitp> | assuming you mean the interfaces defined in Fetch |
| 22:54 | <gsnedders> | yeah |
| 22:55 | <jsbell> | Depends what you mean by "polyfill" too. A useful, forward-compatible subset, certainly. |
| 22:55 | <gsnedders> | I was meaning the whole API |
| 22:56 | <gsnedders> | I mean obviously a subset is doable |
| 22:56 | <caitp> | definitely the streams thing is not really polyfillable, even in browsers with progress events |
| 22:56 | <caitp> | haven't gotten too far into that yet though, living in xhr land :> |
