| 00:10 | <Domenic> | Apparently web-platform-tests differs with the HTML standard about whether input type="email" should be selectable? https://github.com/tmpvar/jsdom/pull/804#issuecomment-47602028 |
| 01:20 | <zewt> | "a principled stance" is a fascinating phrase (assumes that the speaker's set of principles are the only valid ones) |
| 04:02 | <Hixie> | this whole TAG thing is pretty hilarious |
| 04:02 | <Hixie> | i love that all these people think they can only contribute if they're in the TAG |
| 04:03 | SamB | suits up in his <HTML></HTML> tag |
| 05:36 | <cabanier> | Hixie: TAG in general or did they make some statement? |
| 07:11 | <annevk> | cabanier: see www-tag |
| 07:33 | <MikeSmith> | zewt: no it does not assume that |
| 07:33 | <MikeSmith> | zewt: I haven't read yet the context but in general it doesn't imply that at all |
| 07:33 | <MikeSmith> | zewt: in fact it often implies the opposite |
| 07:35 | <MikeSmith> | zewt: it's often used to acknowledge that while you disagree with someone else's argument, you respect the position they've taken on it as being one based on principles, though you may disagree with the priorities of those principles over other concerns, or with the principles themselves |
| 07:36 | <MikeSmith> | Domenic: if the tests differs from the spec then it should be raised as an wpt issue and/or as a PR |
| 07:37 | <MikeSmith> | Domenic: ah I see you already said as much in the issue thread |
| 07:43 | <SamB> | MikeSmith: as in a "wow they're really sticking to their principles" type of thing? |
| 07:57 | <jgraham> | Domenic: If the spec and the tests disagree it's presumably a bug in the tests. |
| 07:58 | <jgraham> | Oh, MikeSmith just said that |
| 07:58 | <jgraham> | I should apparently not read a randomly selected subset of the scrollback |
| 08:23 | <annevk> | MikeSmith: I opened https://github.com/masinter/multipart-form-data/issues/17 |
| 08:23 | <annevk> | I'll also watch the repository for a bit |
| 08:26 | <odinho> | SamB: Well, in fact chrome. I think it makes sense to develop more of the web platform in javascript. From low-level primitives given from the engine c++ land. |
| 08:45 | <MikeSmith> | annevk: gool |
| 08:45 | <MikeSmith> | erp cool |
| 08:46 | <jgraham> | Oh, I assumed that was an unlikely typo for "good". Although now it sounds like some sort of football celebration |
| 09:01 | <annevk> | I thought it was a reference to https://twitter.com/hober/status/483296410108833793 & https://twitter.com/hober/status/483296772941283328 |
| 09:40 | <MikeSmith> | "Web Components as currently designed cannot explain the behavior of any built-in elements (except maybe those which can be explained with CSS alone)." |
| 10:07 | <JakeA> | annevk: body.asJSON - we decided they consume the stream rather than tee it, right? Was there a reason for that? Maybe it should tee. |
| 10:21 | <annevk> | JakeA: as*allthethings don't tee |
| 10:21 | <annevk> | JakeA: elaborate? |
| 10:22 | <JakeA> | annevk: If they tee, you can call them multiple times, or call asBlob then asText. I'm not sure it's intuitive that they're one-off at the moment. What's the advantage? |
| 10:23 | <annevk> | JakeA: you don't have to keep the response around |
| 10:24 | <JakeA> | annevk: I can see that being an issue if the object is kept in reference long after calling asWhatever, not sure that's likely though |
| 10:26 | <annevk> | The design of responseType / response on XMLHttpRequest was exactly because of this |
| 10:26 | <annevk> | The original design of having both responseText and responseXML was a memory issue, and that's why we didn't add responseBlob |
| 10:33 | <JakeA> | annevk: adding responseBlob wouldn't have added extra memory overhead though, the blob would have been constructed as part of the getter right? |
| 10:34 | <annevk> | JakeA: the problem was that you could never toss away the original bytes if someone e.g. had already asked for responseText |
| 10:35 | <annevk> | JakeA: if streams support something like tee(), then subclasses of streams will too, and you could just do .body.tee().asText() |
| 10:37 | <JakeA> | annevk: Yeah, I get the original bytes thing, I didn't realise that'd be a huge problem as the object is likely to get gc'd shortly afterwards anyway. But yeah, body.tee().asText() seems fine. |
| 10:39 | <annevk> | I think people are rightly concerned about memory usage. If we offer a low-level API such as this it seems good to make that usage explicit. |
| 10:40 | <annevk> | We will need to support a tee operation, there's numerous places that require tee/copy |
| 10:40 | <JakeA> | slightlyoff: see above. |
| 10:40 | <annevk> | E.g. the stream that is passed to fetch()'s Request object will need to be teed |
| 10:40 | <JakeA> | Yeah, makes sense |
| 10:40 | <annevk> | tee'd? |
| 10:42 | <annevk> | JakeA: we are going to rename navigate to "topframe" and "child" to "frame" most likely |
| 10:42 | <annevk> | JakeA: see https://www.w3.org/Bugs/Public/show_bug.cgi?id=26247 |
| 10:43 | <annevk> | jungkees: ^^ |
| 10:46 | <JakeA> | annevk: feels like we need a "navigate" helper to cover "topframe", "frame" and "popup" |
| 10:47 | <JakeA> | since navigates are the cases you'd want to provide a "no connection" fallback page, or something |
| 10:47 | <annevk> | JakeA: https://github.com/slightlyoff/ServiceWorker/issues/345 |
| 10:47 | <annevk> | JakeA: "client request" was that term |
| 10:48 | <annevk> | JakeA: as you demonstrate, "navigate" makes you forget about workers |
| 10:49 | <JakeA> | annevk: that was deliberate, in this case |
| 10:50 | <JakeA> | annevk: I wouldn't want to serve up a "Sorry no connection" page in response to a sharedworker request |
| 10:50 | <JakeA> | annevk: But I understand why sharedworkers are in that grouping, as they can make requests themselves |
| 10:51 | <annevk> | isNavigateRequest, isClientRequest could be on Request I suppose |
| 10:51 | <annevk> | Or on FetchEvent, depending on where context/client end up |
| 10:52 | <annevk> | We also haven't really dealt with <object> yet |
| 10:53 | <JakeA> | annevk: <img src="//otherorigin/whatever.svg"> - is this a client request? |
| 10:53 | <JakeA> | I guess not |
| 10:53 | <annevk> | no |
| 10:53 | <JakeA> | but will requests triggered by whatever.svg go through the page's SW, and are we leaking by doing so? |
| 10:53 | <annevk> | client requests and resource requests are mutually exclusive |
| 10:54 | <JakeA> | I guess it's the same as CSS at that point |
| 10:54 | <annevk> | (except maybe for <object>, which does both...) |
| 10:54 | <annevk> | if you load an SVG as an image it cannot do any further fetches |
| 10:54 | <JakeA> | annevk: hopefully we can reuse a lot of appcache's mess when it comes to <object> |
| 10:54 | <JakeA> | annevk: ah, phew, problem solved |
| 10:55 | <annevk> | (at least not network fetches) |
| 10:57 | <hsivonen_> | is there a term to describe something that looks like trolling but may not be motivated by trolling intent? |
| 10:58 | <hsivonen> | like appealing to the behavior of "newer browsers" when requesting a spec change and giving Emacs Web Wowser as an example of such a newer browser |
| 10:58 | <annevk> | pedant |
| 10:58 | <jgraham> | Doesn't sound like pedantry |
| 10:59 | <jgraham> | Sounds like being divorced from the real world |
| 11:00 | annevk | finds phantasmagoric |
| 11:01 | <annevk> | That's some phantasmagoric shit right there |
| 11:02 | <annevk> | JakeA: maybe we should just not do the weird thing appcache did and always route them through the SW? |
| 11:02 | <annevk> | meh |
| 11:02 | <annevk> | hard |
| 11:06 | <JakeA> | annevk: which SW? |
| 11:07 | <Ms2ger> | annevk, JakeA: please don't call it tee(), though |
| 11:07 | <JakeA> | annevk: the page's or the one that would be used if it were a navigation |
| 11:08 | <annevk> | JakeA: the page |
| 11:09 | <annevk> | JakeA: although I guess sometimes you do know upfront the page wants to navigate |
| 11:09 | <annevk> | JakeA: well, does <object name=x></object> <a href=... target=x>...</a> work? would need to test :/ |
| 11:16 | <jungkees> | annevk: thanks for the pointer. will keep an eye on it |
| 11:24 | <hsivonen> | annevk: you might be interested in https://bugzilla.mozilla.org/show_bug.cgi?id=1003716 |
| 11:24 | <hsivonen> | particularly, exposing menus that have items for both ISO-8859-1 and windows-1252 to the user |
| 11:25 | <hsivonen> | even though both encode and decode the same |
| 11:25 | <hsivonen> | so it's basically exposing the decision of which label to put in email headers to the user |
| 11:25 | <hsivonen> | which is sad UI |
| 11:25 | <hsivonen> | I'm not sure if I have the stamina to bikeshed that one anymore |
| 11:27 | <hsivonen> | (Thunderbird has code that specifically picks the windows-1252 encoder even if the outgoing encoding is ISO-8859-1, which is a distinc encoding internally in Gecko, still) |
| 11:31 | <annevk> | hsivonen: why do they even expose technical terms to end users? |
| 11:46 | <JakeA> | annevk: so the page SW would control the load of the <object></object> document, but what about the subresources? Through the child document's SW? |
| 12:17 | <annevk> | JakeA: hmm yeah, would have to do some more digging as to how that entire thing is setup |
| 12:19 | <annevk> | hsivonen: fwiw, I do think that new software should use the Encoding Standard, otherwise we get into the situation where for each format there's a debate about whether the Encoding Standard can be a normative reference |
| 12:19 | <annevk> | hsivonen: which would just suck and complicate everything for no good reason |
| 12:59 | <Jirka_> | annevk: if all new software will use the Encoding Standard and non-UTF encodings will be allowed then you will loose interop with existing encoding libraries in JDK/.NET/iconv/... |
| 13:03 | <annevk> | Jirka_: yes |
| 13:06 | <zewt> | it's not really losing interop if they didn't have interop with each other in the first place |
| 13:10 | <Jirka_> | annevk: What about spliting the Encoding Standard into two documents -- one will define only UTF-8 related stuff and JS APIs and second will define how to handle legacy web resources in non-UTF encodings. Any new software will be then built on top UTF-8-only Encoding Standard, no need to deal (and possibly create confusion) with legacy encodings |
| 13:12 | <caitp> | yeah you can never have to many documents to not read! |
| 13:12 | <caitp> | oh man, typo ruined sarcasm =( |
| 13:12 | <zewt> | if people won't follow a simple "only use utf-8" instruction, breaking specs apart isn't going to help--and it's a pain in the ass to do, for everyone involved |
| 13:13 | <annevk> | Jirka_: I don't really see what problem that solves |
| 13:13 | <annevk> | Does this make sense: |
| 13:13 | <annevk> | <p>To <dfn>byte lowercase</dfn> a byte sequence, means replacing any byte in the range |
| 13:13 | <annevk> | 0x41 to 0x5A of the byte sequence with their corresponding byte in the range 0x61 to 0x7A. |
| 13:14 | <annevk> | s/means replacing/replace/ |
| 13:14 | <zewt> | also it seems like the entire point of "new software should use this spec" is exactly *for* legacy encodings ... interop on utf-8 itself isn't a problem |
| 13:14 | <annevk> | there's some interop problems around utf-8, but yes |
| 13:14 | <zewt> | annevk: makes sense but does require interpretation |
| 13:15 | <annevk> | should I do s/their/the/? |
| 13:15 | <zewt> | the only interop issue with utf-8 i've really seen is overlong sequences, and that's uncommon |
| 13:15 | <annevk> | I'm not talking about 5/6 byte sequences, but amount of U+FFFD emitted during error handling |
| 13:16 | <jgraham> | annevk: s/their/the/ is what I was going to suggest |
| 13:16 | <zewt> | could say something like "adding 0x20 to any byte of the byte sequence in the range 0x41 to 0x5A" |
| 13:16 | <annevk> | that might be better |
| 13:16 | <annevk> | thanks |
| 13:17 | <zewt> | is it clear that it's an inclusive range |
| 13:17 | <zewt> | (aside from "duh") |
| 13:18 | <annevk> | <p>To <dfn>byte lowercase</dfn> a byte sequence, increase each byte it contains in the range 0x41 to 0x5A by 0x20. |
| 13:18 | <Jirka_> | annevk: current reading of the Encoding Standards and legacy encodings seems to cover all usages of legacy encodings and not only those on the web. |
| 13:18 | <annevk> | zewt: yeah, I need to clarify that at some point, that's a bigger issue though :/ |
| 13:19 | <annevk> | Jirka_: yes that is intended |
| 13:20 | <annevk> | Jirka_: it would be weird to allow some CSS or XML to be interpreted in different ways |
| 13:20 | <zewt> | i imagine there are many encodings that exist but which aren't used on the web, in which case they wouldn't be in the encoding spec (but I guess if that's a problem for some cases they could write a spec for just those encodings) |
| 13:20 | <zewt> | (that are used, not just exist) |
| 13:22 | <annevk> | It would be a problem if they leak, which is why I think protocols and formats ought to be based on the Encoding Standard or only allow utf-8 |
| 13:22 | <zewt> | heh i think ircd does case-insensitive comparisons with just chr | 0x20, since iirc it treats { and } as equal to [ and ] for nicks |
| 13:22 | <annevk> | (and then the flavor of utf-8 defined by the Encoding Standard) |
| 13:23 | <Jirka_> | annevk: IMHO legacy encoding in CSS could (and should be) handled in the same way as in HTML. However for legacy encodings XML parsers in browsers are not interoperable -- neither between some browsers not with non-browser implementations |
| 13:23 | <zewt> | (not aware of there being multiple "flavors" of utf-8) |
| 13:23 | <annevk> | Jirka_: browsers are not always interoperable either when it comes to encodings, I would consider all that to be a bug |
| 13:23 | <annevk> | zewt: error handling issue mentioned above |
| 13:30 | <caitp> | zewt: iirc there are bits reserved for application-specific purposes which might be accidentally transmitted and understood differently by different agents --- I can't recall what that's called, though. so you could think of that as "different flavours" |
| 13:30 | <zewt> | i'd call that "not utf-8 at all" |
| 13:30 | <caitp> | well, it's not meant to be exposed to anyone outside of the application, that's for sure =) |
| 13:31 | <caitp> | just think of it as utf8 with some extra bonus garbage |
| 13:31 | <annevk> | I'm not talking about CESU-8 or variants of that |
| 13:31 | <zewt> | not aware of any "reserved bits" in utf-8, either |
| 13:31 | <caitp> | CESU-8, that sounds like what I'm thinking of |
| 13:33 | <zewt> | i wonder if it's possible to satisfy the FFFE definition (efficiently) while seeking backwards in utf-8 |
| 13:34 | <zewt> | guessing not |
| 13:36 | <zewt> | actually you probably could... that is, generate FFFEs without having to seek backwards without bound to figure out how many to generate (but you don't actually need to know how many, only whether you should be generating one more or not) |
| 13:39 | <Philip`> | zewt: (JNI has its own special UTF-8 - http://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/types.html#wp16542) |
| 13:39 | <zewt> | that's also just Not UTF-8(tm) |
| 13:39 | Philip` | has no idea how likely that is to leak out in the external world |
| 13:41 | <caitp> | it's not the greatest encoding in the world, it's just a tribute |
| 13:54 | <JakeA> | annevk: In APIs like thingOfThings.create(newThingName), if newThingName already exists, do we generally throw or return the existing thing? |
| 13:54 | <JakeA> | In idb it throws. Any other cases? |
| 13:55 | <JakeA> | annevk: Going to change the caches API. Rather than caches.add(name, new Cache(...)) it'll be caches.create(name).then(function(cache) {}) |
| 13:55 | <JakeA> | Trying to work out what's best if the cache already exists |
| 13:55 | <jgraham> | Create not creating seems pretty confusing |
| 13:57 | <jgraham> | (if you called it "set" it would be less confusing) |
| 13:57 | <JakeA> | I guess if you want the get-or-create behaviour it's caches.get(name).catch(e => caches.create(name)) |
| 13:58 | <jgraham> | Actually I guess it wouldn't |
| 13:58 | <annevk> | JakeA: well e.g. createElement() would always succeed |
| 13:59 | <JakeA> | annevk: yeah, but what about where the name is unique (like caches or idb databases) |
| 13:59 | <annevk> | JakeA: throwing or overwriting seems expected from maps? |
| 13:59 | <jgraham> | Yeah, there isn't much precedent on the platform for having this kind of datastructure |
| 14:00 | <jgraham> | Right, I was assuming that overwriting wasn't sensible for some reason |
| 14:00 | <jgraham> | if it is, then I would really expect that |
| 14:01 | <JakeA> | Yeah, that works pretty well. So caches.create(name) would replace 'name' with an empty cache even if one existed |
| 14:02 | <annevk> | JakeA: if it's a map, maybe just name it set then |
| 14:02 | <annevk> | JakeA: although at that point you're back at add() :p |
| 14:02 | <jgraham> | It's an async map, right? |
| 14:03 | <jgraham> | Only not quite |
| 14:03 | <JakeA> | jgraham: Sorta, but we're not defining an async map type |
| 14:03 | <jgraham> | It's an async default map |
| 14:03 | <jgraham> | JakeA: Well you are, just in DOM rather than ES |
| 14:04 | <jgraham> | Which is fine |
| 14:04 | <JakeA> | Here's the pattern I'm looking at https://gist.github.com/jakearchibald/69bdd0c49d205717963e |
| 14:06 | <JakeA> | "set" doesn't feel right. I'd expect "set" to take two args, key & value. |
| 14:07 | <jgraham> | Yeah, I agree |
| 14:08 | <jgraham> | This is doing special magic with the key to implicitly create a value |
| 14:08 | <jgraham> | Or maybe not with the key |
| 14:08 | <JakeA> | I don't think there's any magic |
| 14:08 | <JakeA> | it's just the key |
| 14:09 | <JakeA> | it's not like createElement |
| 14:09 | <JakeA> | caches.create(name) caches.get(name) caches.delete(name) |
| 14:09 | <JakeA> | it's most similar to idb's create database method |
| 14:10 | <JakeA> | (which throws if a database of that name already exists, so we could do the same as that, but I'm not convinced idb is a great thing to copy) |
| 14:10 | <jgraham> | Sure. I just mean that it's not a generic operation, it's specific to this particular type of object |
| 14:10 | <JakeA> | yeah |
| 14:12 | <jgraham> | (or, I guess, it is probably something that *could* be applicable to many types of objects, but you would need some kind of protocol for specifying the code that create() runs to generate a value. Which doesn't seem worth abstracting out) |
| 14:14 | <annevk> | JakeA: so is it a map or a set of caches? |
| 14:16 | <jgraham> | annevk: IAFAICT it's an (async) map of caches |
| 14:16 | <jgraham> | *AFAICT |
| 14:16 | <annevk> | oh right, name -> cache |
| 14:16 | <annevk> | sorry |
| 14:16 | <annevk> | so yeah, create makes sense |
| 14:17 | <JakeA> | annevk: What jgraham said, although all values are forced to be caches, all keys are forced to be strings, uniqueness is enforced in values |
| 14:17 | <annevk> | I think following IDB and throwing is fine for duplicates, provided there's has() |
| 14:17 | <annevk> | You probably don't want to accidentally erase a bunch of resources |
| 14:18 | <annevk> | JakeA: please do respond to the various issues open against this API btw |
| 14:18 | <JakeA> | annevk: Problems with the current API: var myCache = new Cache(); caches.add('foo', myCache); caches.add('bar', myCache); |
| 14:18 | <annevk> | JakeA: especially the one about it having the wrong name |
| 14:18 | <annevk> | JakeA: what if instead you did it as new Cache(name) |
| 14:19 | <annevk> | JakeA: and then cache.add(myCache) |
| 14:19 | <annevk> | and then cache.getByName(name) |
| 14:19 | <annevk> | so it's a set with identifiers on the objects |
| 14:20 | <annevk> | and add() would simply throw if either cache or name was already present |
| 14:21 | <JakeA> | annevk: Yeah, aware of the wrong name one. Not convinced "cache" is bad, but not strongly opposed to changing it. |
| 14:21 | <annevk> | I think the argument from Brendan about Cache not being persistent is quite persuasive |
| 14:22 | <JakeA> | yeah |
| 14:25 | <JakeA> | annevk: So, var myCache = new Cache("static-v1"); caches.add(myCache); caches.getByName("static-v1")? That solves the unique issue, but feels weird being able to create these cache things without them being part of the thing that persists them. |
| 14:26 | <JakeA> | Although I suppose that's true of blobs & idb too, but I don't think a cache is useful outside of caches |
| 14:32 | <JakeA> | annevk: just saw https://twitter.com/annevk/status/483974642336825344 |
| 14:32 | <JakeA> | ugh |
| 14:32 | <annevk> | heh, that's what I said |
| 14:33 | <JakeA> | I'm not aware of the consensus here |
| 14:33 | <annevk> | JakeA: so with this you could imagine transferring the Cache() between apps |
| 14:33 | <annevk> | JakeA: you can transfer it between domains even if we support cloning on it |
| 14:34 | <JakeA> | annevk: Transferring between apps? Something like caches.copy(name, otherName)? |
| 14:34 | <annevk> | It seems like you need Cache to exist as an object either way |
| 14:35 | <annevk> | now like otherapp.postMessage(cache) |
| 14:35 | <annevk> | s/now/no/ |
| 14:35 | <annevk> | potentially otherapp.postMessage(cache, [cache]) if we support transfering |
| 14:36 | <JakeA> | caches.get(name).then(function(cache) { otherap.postMessage(cache); }) |
| 14:37 | <annevk> | yeah |
| 14:39 | <JakeA> | annevk: That's already possible in the .create & .get model, but if you got a cache via postmessage you wouldn't be able to get it back into caches. Hmm. |
| 14:41 | <annevk> | I kind of like what I proposed above |
| 14:41 | <annevk> | var files = new Cache(files); caches.add(files, ...) |
| 14:42 | <JakeA> | new Cache("files"); right? |
| 14:47 | <Domenic> | i agree that that is a bit weird ... not horrible though |
| 14:47 | <JakeA> | Domenic: what is? |
| 14:47 | <Domenic> | what is the problem with caches.set('name1', c); caches.set('name2', c) ? |
| 14:48 | <Domenic> | JakeA: var c = new Cache('name'); caches.add(c); seems a bit weird, but not horrible. |
| 14:48 | <annevk> | JakeA: yes |
| 14:49 | <JakeA> | Domenic: having some caches be === feels complicated and unuseful |
| 14:49 | <Domenic> | JakeA: that's not my mental model. My mental model is there's still only one cache object, but it got put in two entries in the cache-map |
| 14:50 | <Domenic> | JakeA: the same as `var x = {}; var m = new Map(); m.set('key1', x); m.set('key2', x);` |
| 14:50 | <Domenic> | is that the wrong mental model? |
| 14:50 | <JakeA> | Domenic: No, but is there anywhere else we do that with permanent storage? |
| 14:51 | <Domenic> | JakeA: I dunno, but, is caches really a permanent storage model, or is it an async map? |
| 14:51 | <Domenic> | that is, when you store something in caches, do you serialize it? |
| 14:51 | <Domenic> | i think serialization is what draws the line for "permanent storage" vs. "async map" for me |
| 14:52 | <wanderview> | annevk: it seems with |var files = new Cache(files); caches.add(files, ...)|, we would still might want to store stuff to disk even if it hasn't been added to caches yet |
| 14:52 | <wanderview> | annevk: otherwise someone could add many large resources to the cache and we would have to maintain them all in memory |
| 14:52 | <Domenic> | Yes, wanderview makes a good point... at what point do things get put into disk vs. in-memory? |
| 14:53 | <wanderview> | I could see that as a common footgun too... new Cache, add all my resources, put in caches at the end |
| 14:53 | <Domenic> | well, until it gets GC'ed, I can't imagine ever being able to evict them from memory... |
| 14:54 | <Domenic> | just saying that you put it on disk doesn't mean it can move out of memory |
| 14:55 | <wanderview> | Domenic: can't we stream the resources to disk and only read into memory if there is an outstanding Promise<Response>? |
| 14:55 | <JakeA> | At the moment, in the current API: var cache = new Cache(); cache.add(things...); |
| 14:55 | <JakeA> | I'd expect stuff to be written to disk because of the memory issue |
| 14:56 | <JakeA> | but if that isn't added to `caches`, it'd be deleted when `cache` is gc'd |
| 14:56 | <wanderview> | JakeA: yea, I think thats possible, but its a bit of a complication to clean up the filesystem on GC I think |
| 14:56 | <JakeA> | The caches.create('name').then(c => c.add(things...)) model prevents that |
| 14:56 | <Domenic> | wanderview: if the things you add to the cache are accessible as local variables in JS anyway (including temporary ones), you can't remove them from memory until they get GCed ... right? |
| 14:57 | <wanderview> | Domenic: I guess I was thinking of the cache.add(requests...) case... where content is pre-loading the cache and not explicitly waiting for the response |
| 14:57 | <Domenic> | JakeA: OK, that is helpful. So we are saying in-memory caches are not useful? Or are we saying that new Cache() would still work, but caches.create('name') is a way of getting one that is synced to storage |
| 14:57 | <JakeA> | Although there's still cache.get('name').then(function(cache) { caches.delete('name'); }) |
| 14:58 | <JakeA> | So deleting from disk on gc is still needed |
| 14:58 | <Domenic> | JakeA: for testability if nothing else I would think in-memory caches are useful. |
| 14:58 | <JakeA> | unless we can put cache objects in some kind of "disabled" state |
| 14:58 | <Domenic> | this is going down a dark path |
| 14:58 | <wanderview> | JakeA: or we replace caches.delete() with cache.deleteFromCaches() or something... but thats kind of ugly :-( |
| 14:59 | <Domenic> | wanderview: that doesn't help, cache still exists in memory. |
| 14:59 | <Domenic> | wanderview: unless deleteFromCaches() also puts it in some sort of disabled state |
| 14:59 | <JakeA> | the disabled state thing feels ugh |
| 15:00 | <annevk> | wanderview: hmm, don't we have an equivalent problem with new File() or new Blob()? |
| 15:00 | <Domenic> | yes please don't, if possible |
| 15:00 | <wanderview> | I think dealing with the GC file eviction is required |
| 15:00 | <wanderview> | annevk: yea, maybe its not the problem I think it is |
| 15:00 | <JakeA> | (brb, meeting) |
| 15:00 | <wanderview> | its a complication, but probably a solved one |
| 15:01 | <Domenic> | why is it caches.each() instead of caches.forEach() O_O |
| 15:01 | <annevk> | Domenic: the browser might serialize it |
| 15:02 | <Domenic> | annevk: can't tell what that's in response to |
| 15:02 | <wanderview> | question... var c = new Cache(); c.add(requests...); without putting in caches count against the origin's disk quota? |
| 15:02 | <annevk> | Domenic: or try to keep it alive in some other way |
| 15:02 | <wanderview> | I think it must as we will want the flexibility to save to disk at any time... just wanted to clarify since we were talking about "memory only" cache objects |
| 15:02 | <annevk> | Domenic: the cache API is a permanent storage model (and therefore has the wrong name) |
| 15:03 | <Domenic> | annevk: is the cache API permanent, or is the caches API permanent? |
| 15:03 | <annevk> | well only caches is something that survives a reboot |
| 15:03 | <Domenic> | wanderview: I think that makes sense, as long as the programmer's mental model is that it's entirely in-memory until explicitly saved? |
| 15:04 | <Domenic> | each vs. forEach filed https://github.com/slightlyoff/ServiceWorker/issues/351 |
| 15:05 | <wanderview> | Domenic: hmm... I guess I was trying to say I will want to write to disk immediately to allow us to GC memory when possible, so not sure we are on the same page... what is the "explicit save" step in your view? |
| 15:05 | <Domenic> | wanderview: well from my perspective that's what's being discussed in this chat :) |
| 15:06 | <Domenic> | wanderview: so e.g. in the existing `var c = new Cache(); caches.set('name', c)` API, the `caches.set()` step saves to disk |
| 15:06 | <Domenic> | wanderview: whereas in the `caches.create('name').then(c => ...)` API, it is created-and-saved in the same step |
| 15:06 | <Domenic> | although "saved" is the wrong word |
| 15:06 | <Domenic> | more like... "made into something that is backed by persistent storage" |
| 15:07 | <Domenic> | versus in-memory only (from the programmer's point of view, even if the implementation puts some stuff on disk for its own reasons) |
| 15:07 | <Domenic> | the `var c = new Cache(); /* never store it in caches */` usage would be "in memory only" and useful for testing and such. |
| 15:07 | <wanderview> | Domenic: hmm, so in that case it would *not* count against quota until the caches.set() |
| 15:08 | <Domenic> | I think so, yeah... if that works from a disallowing-abuse POV |
| 15:08 | <Domenic> | or maybe there are separate temporary and persistent quotas |
| 15:08 | <annevk> | Cache should use the same quota as Blob I suppose |
| 15:08 | <annevk> | but I can see how it all gets rather tricky :/ |
| 15:09 | <wanderview> | Domenic: I guess I just worry about people waiting to call caches.set() at the end in order to avoid a partial cache object |
| 15:09 | <Domenic> | annevk: agreed, same as Blob makes a lot of sense... |
| 15:09 | <wanderview> | I'm sure we can make it work |
| 15:09 | <Domenic> | wanderview: well, I think a caches.create('name') API would mitigate that |
| 15:10 | <Domenic> | the constructor could be a lower-level API used by unit tests and such |
| 15:10 | <Domenic> | whereas the best practice if you want a persistent cache would be caches.create |
| 15:10 | <wanderview> | Domenic: yea, I guess its an education issue (although at some point those become footguns) |
| 15:10 | <Domenic> | At this point it all makes sense in my head; curious what JakeA thinks :) |
| 15:11 | <wanderview> | Domenic: what is the advantage of memory-only for testing vs. what we recommend for production use? |
| 15:11 | <JakeA> | Domenic: will read through when this meeting is done (yey for meetings) |
| 15:12 | <Domenic> | wanderview: if you are not very careful, you will fill up your persistent storage with repeated unit-test data |
| 15:13 | <wanderview> | good point |
| 15:37 | <annevk> | I emailed the HTTP WG about an issue... but why? *cries* |
| 15:39 | <caitp> | it's going to be okay anne |
| 15:41 | <annevk> | caitp: that's what they said last time |
| 15:56 | <SamB> | Domenic: so this "save" is kind of like migrating stuff from /tmp or /var/cache to /var/lib ? |
| 15:57 | <Domenic> | SamB: from my perspective as a JS developer /tmp is an implementation detail of the browser |
| 15:57 | <Domenic> | SamB: it could be in-memory for all I care |
| 15:57 | <SamB> | /tmp CAN be in-memory |
| 15:57 | <SamB> | anyway this is a metaphor |
| 15:57 | <Domenic> | yes, well, there you go |
| 15:57 | <Domenic> | the only observable thing (as far as I can tell) is whether the data survives a reboot |
| 15:59 | <SamB> | and naturally, JS apps don't really get to complain if data turns out to survive that they wouldn't have expected to survive, right? |
| 15:59 | <Domenic> | well, it should not observably survive |
| 15:59 | <SamB> | hmm |
| 15:59 | <annevk> | Domenic: is there a document that explains why we don't want to expose promise state? |
| 16:00 | <SamB> | so maybe not the /var/cache part then; that can only *theoretically* get nuked, afaict |
| 16:00 | <SamB> | I mean, stuff is still supposed to work if you nuke it, but I've not heard of any automatic process which would nuke it |
| 16:01 | <Domenic> | annevk: hmm. we don't want to expose, or we don't want to allow external modification of? |
| 16:01 | <annevk> | Domenic: don't expose I guess |
| 16:02 | <Domenic> | annevk: I don't think exposing is bad. Several promises libraries have promise.inspect() that returns e.g. { state: "fulfilled", value: [whatever] } |
| 16:02 | <Domenic> | the use cases are dubious however |
| 16:03 | <Domenic> | i guess it kind of encourages zalgo code? |
| 16:03 | <Domenic> | if (promise.inspect().state === "fulfilled") { runUserCodeWith(promise.inspect().value); } else { promise.then(runUserCodeWith); } |
| 16:03 | <Domenic> | zalgo in action |
| 16:14 | <annevk> | ta |
| 16:47 | <JakeA> | Domenic: re each vs forEach, we didn't want to use a name that may be taken by asyncmap, as the behaviour of cache.each may differ |
| 16:48 | <JakeA> | Oh you made a ticket |
| 16:53 | <JakeA> | annevk: Domenic: exposing promise state would have helped in this case https://github.com/jakearchibald/trained-to-thrill/blob/master/www/static/js/app.js#L64-74 - means I wouldn't need showingLiveData. |
| 16:54 | <JakeA> | Domenic: Done the read-back. Are you suggesting `caches.create('name')` work, but also `new Cache()`? |
| 18:05 | <Domenic> | JakeA: yes, I think so, at least. new Cache() is in memory; caches.set('name', c) and/or c.makePersistentVia(caches) makes c persistent; caches.create('name') combines the two at once as a sugar layer |
| 18:06 | <annevk> | JakeA: maybe file a bug on the promise spec? |
| 18:06 | <annevk> | Domenic: we need to start thinking about ES7-promises |
| 18:07 | <annevk> | Domenic: at least finally, we should add finally |
| 18:07 | <Domenic> | annevk: agreed on that one |
| 18:07 | <Domenic> | annevk: I can have an extension spec written up as an "ES7 track proposal" for next TC39; if everyone likes it then everyone can implement it ASAP. |
| 18:07 | <Domenic> | (ES is a living standard; they just don't know it yet.) |
| 18:08 | <annevk> | Domenic: sgtm (is that enough? :p) |
| 18:08 | <Domenic> | :P |
| 18:08 | <Domenic> | JakeA: I'm not sure the code would look *that* much better. I dunno, it's pretty rare. Perhaps more common than Promise.race, I'll grant you. |
| 18:26 | <annevk> | http://annevankesteren.nl/2014/06/vats now with analogies |
| 18:27 | <MikeSmith> | _win 30 |
| 18:34 | <Hixie> | "ES is a living standard; they just don't know it yet" <- i wish it was that simple :-) |
| 18:38 | <Domenic> | From the perspective of implementers, it's pretty close. |
| 18:38 | <Domenic> | the messaging is all screwed up |
| 18:38 | <Domenic> | but there are "ES7" things that are shipping, and "ES6" things that are nowhere near done or even started on implemnetatios |
| 18:38 | <Domenic> | and those ES7 things are locked whereas the ES6 things change all the time |
| 18:39 | <Domenic> | So stability is directly proportional to shipping or not |
| 18:39 | <Domenic> | and people are starting to realize this |
| 18:41 | <Ms2ger> | Domenic, people *here* know that ;) |
| 18:42 | <Domenic> | annevk: those are good analogies |
| 18:42 | <Hixie> | it's definitely not a living standard in the HTML sense from the perspective of implementors, in my experience |
| 18:42 | <Hixie> | i've asked implementors "how about we add foo to ES" and they say "we can'd do that now, because ES is frozen" |
| 18:42 | <Domenic> | I feel like implementers are coming around. I might be over-optimistic.\ |
| 18:43 | <Domenic> | O_O |
| 18:43 | <annevk> | Domenic: I love talking to Allen |
| 20:04 | <Domenic> | How do I create WebIDL "mixins" that don't appear in proto chains or on the global? Is it just [NoInterfaceObject] + always use implements, not : ? |
| 20:06 | <Ms2ger> | Correct |
| 20:07 | <Ms2ger> | The former for "on the global", the latter for "in proto chains" |
| 20:10 | <MikeSmith> | annevk: I know Dominic Clooney well enough to know that he wasn't trying to be contemptuous or dismissive in that bug comment |
| 20:10 | <MikeSmith> | https://code.google.com/p/chromium/issues/detail?id=389124#c8 |
| 20:15 | <MikeSmith> | annevk: I think he should have used different words there but I don't think his comments are indicative of trying to blow anything off |
| 20:17 | <tantek> | MikeSmith - sorry I don't buy that. The very phrase "the consensus within Google" should NEVER be used to justify anything standards related. |
| 20:18 | <tantek> | such a phrase is *political* not technical and is not helpful |
| 20:18 | <annevk> | I got a bit pissed because various times I have heard about Google discussing things internally about service workers / fetch that are relevant to everyone in the community |
| 20:18 | <tantek> | it also implies that there is a "internal standards process" at Google that happens before they send someone to "litigating" their work outside. Also a very poor choice of word. |
| 20:19 | <tantek> | that kind of delayed open behavior is unacceptable |
| 20:19 | <tantek> | so it's right for annevk to call them out on it |
| 20:19 | <tantek> | annevk - you're right to be pissed. |
| 20:19 | <tantek> | those that behave that way at Google have a cultural problem that is antithetical to open standards development. |
| 20:20 | <tantek> | it's fine to "vet" or "double-check" ideas privately, with colleagues, co-workers etc. |
| 20:20 | <tantek> | but any kind of "consensus" discussion should happen in an open space |
| 20:21 | <tantek> | MikeSmith - I accept that there is no ill will. That's not the problem. The problem is one where individuals like in that thread don't even realize that their behavior (perhaps learned from internal culture) is antithetical to open standards development |
| 20:44 | <MikeSmith> | tantek: yeah like I said, I think he could have used some better words there. And yeah I think what he describes is probably not the process that's likely to produce the best results |
| 20:45 | <tantek> | yeah. it however seems to shed light on what may be standard procecdure behind Google's walls. that's the larger concern |
| 20:46 | <Domenic> | I think it's somewhat OK to put the job of interfacing with the wider world on one person's shoulders |
| 20:46 | <Domenic> | Some people are intimidated by standards lists etc. |
| 20:49 | <Ms2ger> | position: sticky is gone from Blink? Bad for mobile perf? |
| 20:51 | <MikeSmith> | Domenic: I think most people are intimidated by standards lists. The ones who aren't are the odd exceptions |
| 20:51 | <Ms2ger> | That does seem like something we should improve |
| 20:52 | <Domenic> | Specifiction seems unintimidating. Although not entirely useful (yet?). |
| 20:52 | <Ms2ger> | Never heard of it |
| 20:53 | <MikeSmith> | Ms2ger: it's something Robin set up |
| 20:53 | <MikeSmith> | Ms2ger: so that automatically means you'll love it |
| 20:53 | <Ms2ger> | Ha |
| 20:54 | <MikeSmith> | Ms2ger: discourse.specifiction.org |
| 20:54 | <Ms2ger> | So what is it? |
| 20:58 | <JonathanNeal> | Ms2ger: it’s an on topic chat room, slowed down. |
| 20:58 | <Ms2ger> | Aha |
| 20:58 | <Domenic> | I think of it as a prototype for replacing mailman |
| 20:58 | <Domenic> | But right now everything is in one big forum so it's pretty unfocuse |
| 20:58 | <Ms2ger> | So it's moving discussion away from where people expect it to be, without telling them? |
| 20:58 | <Ms2ger> | That seems like somewhat poor form |
| 20:59 | <Domenic> | Perhaps. It's an experiment, is the somewhat-buyable excuse. |
| 21:05 | <JonathanNeal> | I like that posts are more thought out than chat and easier to create than a full blog. I fear it might develop an aggressive mob mentality as I’ve seen in GitHub issues, Twitter threads, and the beccapurple Specifiction. |
| 21:09 | <JonathanNeal> | I would also recommend it for all of the creative ideas that appear there, and the notable contributors to the web who chime in with their own responses. |
| 21:10 | <Domenic> | The issue (aside from the now there are two things problem Ms2ger alludes to) is that it's not focused around any particular technology implementers care about. It's kind of like whatwg⊙wo in that way, if more people knew about it. |
| 21:11 | <Domenic> | Except unlike whatwg@, you don't get a guarantee of a personal response from Hixie, so a lot of threads can just become developers saying "I'd like this" or "here's my bikeshed color" with no driving toward a solution. |
| 21:12 | <Hixie> | "I think it's somewhat OK to put the job of interfacing with the wider world on one person's shoulders" <- that's not the problem, the problem is that this job should come _before_ making decisions, not after |
| 21:20 | <Domenic> | well, that's where we get into charitable vs. uncharitable interpretations. Charitable: we want it, and we hope Alex can argue for it successfully, so we're implementing now on that assumption. Uncharitable: we're doing it no matter what; Alex's job is to make other people fall in line. |
| 21:22 | <tantek> | What Hixie said about "this job should come _before_ making decisions, not after" |
| 21:22 | <tantek> | that. |
| 21:23 | <tantek> | Domenic, care to explain how you're interpreting anything charitable from "consensus within Google" ? |
| 21:23 | <tantek> | which sounds awfully like "done deal within Google" |
| 21:24 | <tantek> | and "litigating" sounds like force. I mean at least say something like "negotiating" but even that is bad as it sounds antagonistic. |
| 21:24 | <Domenic> | tantek: I am trying, and possibly failing to combat I'm-a-Googler-now bias. But to me it sounds like "after talking with our security folks, this is the solution we thought would work." |
| 21:24 | <Domenic> | And yes, litigating sounds very bad. Perhaps a word someone who is scared of standards bodies would use. |
| 21:25 | <SamB> | who said that word? |
| 21:26 | <SamB> | and I thought it was more like "now there are 17 competing specs" |
| 21:26 | <tantek> | Domenic - I can understand people disliking (whether for fear or other reasons) standards bodies, or in particular standards mailing lists. |
| 21:26 | <tantek> | SamB talking about https://code.google.com/p/chromium/issues/detail?id=389124#c8 |
| 21:26 | <SamB> | though actually that didn't work out so bad for "menu" |
| 21:27 | <SamB> | I mean, it's kind of dying now that .desktop has come along, but before that it was pretty darn useful |
| 21:27 | <Domenic> | oooh i wonder how the Blink <menu> implementation is coming along |
| 21:27 | <Domenic> | will be so exciting to have that be more than just a Firefox-only feature |
| 21:28 | Domenic | still likes most of the stuff Hixie has come up with, even in our brave new web components world where everyone builds their own |
| 21:28 | <SamB> | "menu" being the debian package that let other packages ship menu entries in *one* format for all WMs |
| 21:28 | <SamB> | even though they all had their own menu formats |
| 21:31 | <tantek> | "world where everyone builds their own" is merely XML "2.0" (in contrast to actual "XML 2.0") |
| 21:31 | <tantek> | I'm going to grab a big bag of popcorn to watch that show |
| 21:39 | <SamB> | hmm, if the idea is to prevent trouble with sites that DON'T WANT service workers, how is a new header on the REQUEST going to help AT ALL? |
| 21:54 | <SamB> | hmm, I guess it could help when a site becomes AWARE of the rogue SW during the 24-hour window |
| 22:05 | <SamB> | https://datatracker.ietf.org/doc/draft-saintandre-xdash-considered-harmful/ expired :-( |
| 22:06 | <Domenic> | Welp, that's it, I guess we all have to add X- back to our headers now |
| 22:08 | <SamB> | lol |
| 22:08 | SamB | really isn't sure the automatic expiry thing is at all useful |
| 22:10 | <SamB> | oh, the tracker is just dumb |
| 22:10 | <SamB> | it didn't really get dropped |
| 22:13 | <tantek> | isn't automatic expiry the complete opposite of living standard? |
| 22:13 | <SamB> | well it would hardly happen to HTML |
| 22:14 | <SamB> | since HTML gets edited way more often than every 6 months |
| 22:16 | <Hixie> | when i was editing an I-D |
| 22:16 | <SamB> | anyway, I really wish there was an obvious place to point out that a draft appears to be an ancestor of another draft, so that someone could make the IETF tools aware of this fact ... |
| 22:16 | <Hixie> | i published every edit as a new version |
| 22:16 | <Hixie> | and they literally complained that this was generating too much work for them |
| 22:16 | <Hixie> | because apparently someone has to manually do something every time you send an update (!) |
| 22:16 | <SamB> | hahaha |
| 22:16 | <SamB> | did you tell them to automate it? |
| 22:17 | <Hixie> | it ended up being a non-issue since i quit editing the spec shortly after |
| 22:17 | <tantek> | "someone has to manually do something every time" - hey that sounds like W3C publication! |
| 22:17 | <SamB> | tantek: yeah, but this was about DRAFTS |
| 22:17 | <tantek> | SamB - same thing - WORKING DRAFTS |
| 22:18 | <SamB> | well, I mean, they don't have like dev.ietf.org or anything |
| 22:19 | <SamB> | Hixie: I suppose, if nothing else, it would tend to spam the mail archive |
| 22:20 | <Hixie> | the idea that one can update a spec too fast was so foreign to me i was baffled |
| 22:20 | <SamB> | anyway evidently that draft somehow ended up as this is RFC 6648/BCP 178 |
| 22:20 | <Hixie> | "please don't fix the errors that quickly" |
| 22:21 | <SamB> | Hixie: maybe what they really meant was "put it up somewhere else if you're gonna fix things that quickly, then just send us a snapshot every week or so" |
| 22:22 | <Hixie> | who knows |
| 22:22 | <Hixie> | seems pretty dumb eitherr way |
| 22:22 | <Hixie> | i mean, either they have the canonical copy, in which case it better have all known bugs fixed, or they don't, in which case, what's the point in theirs existing |
| 22:26 | <tantek> | Hixie as the Mozart of spec editing. "There's just too many edits, make fewer" |
| 22:27 | <tantek> | http://www.toomanynotes.com/Amadeus.htm |
| 22:31 | <SamB> | Hixie: so yeah, maybe they should offer to host ED repos like w3 does ... |
| 22:32 | <SamB> | lol |
| 22:33 | <SamB> | "Which few did you have in mind, Majesty?" |