| 00:09 | <Domenic> | Arrow was pretty good :D |
| 01:14 | <eik> | Hi, In http://www.w3.org/TR/html5/embedded-content-0.html#update-the-image-data talks about update the image data algorithm. I have several questions regarding it - How is this algorithm invoked? Does UI task source enqueue a task to invoke the algorithm? - In step 8 it says that asynchronously await a stable state. What is a stable state in this case? Why can not run the algorithm till step 13 and say run the remaining steps asynchrono |
| 13:33 | <wanderview> | Domenic: we're still on season 1 |
| 16:15 | <Domenic> | wanderview: why is it OK to store an empty body in the cache but not to store a body that's been read-to-the-end? |
| 16:17 | <wanderview> | Domenic: maybe a question for JakeA or annevk, but IMO a drained Response is not the same as a Response with no body... the drained Response does not conceptually capture the true network response any more |
| 16:18 | <Domenic> | Hmm, that fits very poorly with streams. |
| 16:20 | <wanderview> | Domenic: I don't follow... why do you say that? |
| 16:21 | <Domenic> | wanderview: because of what I wrote in the bug ... " If I give you a stream I've read all the chunks from (and thus happens to be closed), that should be the same as some random stream that was never read from but is also closed (because nothing was ever enqueued into it). They behave the same in every respect so there's no point in introducing something new |
| 16:21 | <Domenic> | to differentiate them." |
| 16:21 | <wanderview> | Domenic: without the "don't set used flag if the stream is empty" optimization its all very easy... Cache API looks to see if the stream is closed... if it is, then its "used" |
| 16:22 | <Domenic> | wanderview: right. That's why I was wondering if we could reject for empty bodies. |
| 16:22 | <wanderview> | Domenic: the complexity only comes in trying to special case the "stream is closed, but it doesn't matter because it was empty anyway" condition |
| 16:22 | <Domenic> | Exactly. |
| 16:22 | <wanderview> | Domenic: which unfortunately is already out there in fetch and seems like something reasonably needed for API ergonomics |
| 16:22 | <Domenic> | I don't understand why |
| 16:22 | <wanderview> | why it improves ergonomics? |
| 16:23 | <Domenic> | Is it expected to be common to say res.text() then cache.put(res) but only if res.text() returned ""? |
| 16:24 | <wanderview> | Domenic: the ergonomics mainly come from being able to reuse Request objects... so var req = new Request(url); fetch(req); fetch(req); cache.add(req); |
| 16:24 | <wanderview> | you can reuse the same request for multiple calls that consume if there are no bodies |
| 16:24 | <wanderview> | if there is no body |
| 16:24 | <Domenic> | wanderview: how can you tell there's no body. |
| 16:25 | <wanderview> | without this optimization then you would need: var req = new Request(url); fetch(req.clone()); fetch(req.clone()); cache.add(req.clone()); |
| 16:25 | <wanderview> | Domenic: if its a GET request, there is no body |
| 16:25 | <wanderview> | for example |
| 16:25 | <Domenic> | i see |
| 16:25 | <wanderview> | but I agree, there is no easy way to inspect it |
| 16:25 | <wanderview> | .body.empty :-) |
| 16:25 | <Domenic> | maybe null body vs. empty body makes more sense for GET requests |
| 16:25 | <Domenic> | .body === null |
| 16:25 | <wanderview> | Domenic: I don't think that would be very nice for .body.getReader() |
| 16:26 | <Domenic> | I think it would |
| 16:26 | <wanderview> | now .body.getReader() always needs a if (.body) check first to avoid throwing? |
| 16:26 | <wanderview> | ugh |
| 16:26 | <Domenic> | Yes |
| 16:26 | <Domenic> | Same as fetch() |
| 16:26 | <Domenic> | You're saying people will do multiple fetch()s because they know there's no body |
| 16:26 | <wanderview> | I thought we were trying to unify null/empty concepts... not make it even harder to work with |
| 16:26 | <Domenic> | I'm saying people will not do .body if they know there's no body |
| 16:27 | <Domenic> | It's the same argument |
| 16:28 | <wanderview> | Domenic: what does .body evaluate to if new Request(url, { body: '' })? |
| 16:28 | <Domenic> | wanderview: an empty stream. IMO that should not be multi-fetchable(). |
| 16:29 | <wanderview> | Domenic: I'm not sure what the current spec does with that... might not be multi-fetchable |
| 16:29 | <wanderview> | Domenic: I'm ok with this suggestion... but it seems tyoshino does not like approach |
| 16:30 | <wanderview> | from previous github comments |
| 16:31 | <Domenic> | I will try to outline... |
| 16:35 | <wanderview> | Domenic: thanks, I have to run to lunch but will be back later |
| 16:50 | <yhirano_> | Domenic, in the past discussion you wanted to allow calling text() on a partially consumed response. Is it still your strong preference? |
| 16:52 | <Domenic> | yhirano_: if it can simplify things a lot I could give it up. But I think my proposal in https://github.com/yutakahirano/fetch-with-streams/issues/37#issuecomment-103584177 lets us keep that and is still sane. |
| 16:54 | <terinjokes> | hrm, packaging-on-the-web might be annoying to prollyfil, since each part can have a different content-encoding, so one would have to ship all of iconv |
| 16:54 | <terinjokes> | at least, from my reading |
| 16:55 | <Domenic> | terinjokes: only support utf8 |
| 16:56 | <yhirano_> | Sorry I don't understand. Won't fetch(new Request(url, body: '')) fail with your proposal? |
| 16:56 | <Domenic> | yhirano_: hmm yes, it will as written. that seems bad. i meant it to work once but not twice. |
| 17:55 | <wanderview> | Domenic: why will that one fail? |
| 17:56 | <Domenic> | wanderview: haven't read the 11 responses since I got back, but, off the bad body will be a closed stream, and in my proposal fetch()ing a closed stream will fail. |
| 17:56 | <Domenic> | s/bad/bat |
| 17:56 | <wanderview> | Domenic: I thought I read in a previous comment there was an initial "readable" state and it only went truly closed on first read() |
| 17:56 | wanderview | goes to look at the spec again |
| 17:57 | <wanderview> | Domenic: oh... I was thinking of the state attribute... I guess that went away when we switched to Promise-returning read() |
| 17:57 | <Domenic> | wanderview: even before, once the controller of the stream calls close(), the stream is closed. |
| 17:58 | <wanderview> | Domenic: so there is no way to use .body.getReader().closed here somehow? |
| 17:59 | <Domenic> | wanderview: no, empty body will be immediately closed. |
| 18:00 | <Domenic> | an empty closed stream is the same as a drained closed stream. |
| 18:00 | <Domenic> | streams don't retain knowledge of how they've been interacted with; they just have a current state. |
| 18:00 | <wanderview> | Domenic: well... new Request(url, { body: '' }) could just set body to null as a special case... not sure that works with the other body constructor options, though |
| 18:01 | <Domenic> | yeah I was thinking that... |
| 18:03 | <wanderview> | Domenic: what about creating a wrapper ReadableStream for Request/Response that handles this extra logic |
| 18:10 | <Domenic> | wanderview: seems plausible, although annoying... I am losing sight of what we're gaining for all this complexity ... I think it is the ability to fetch() some requests multiple times but not others? |
| 18:11 | <wanderview> | Domenic: well... this behavior has been released in fetch for some time now... even if we don't like it, not sure we can get rid of it |
| 18:11 | <Domenic> | I kind of wish it was a .body() function now so we could say the moment you call it we switch into sane mode... |
| 18:12 | <wanderview> | Domenic: its not too late for that |
| 18:12 | <wanderview> | but I don't think extra modes would be a good thing |
| 18:13 | <wanderview> | Domenic: as a side note... I do think it would be nice to have a synchronous way to get the stream state... it seems right now everything is async through .read() or .closed promise... right? |
| 18:14 | <Domenic> | wanderview: yes, that is intentional because otherwise it causes GC observability issues, IIRC. |
| 18:14 | <wanderview> | Domenic: hmm... not sure I follow |
| 18:14 | <Domenic> | I don't remember the details... probably somewhere in that big GC thread... |
| 18:15 | <wanderview> | Domenic: I can see GC observability for a callback of some kind... but a sync attribute can't be accessed if the objects it on is GC'd... |
| 18:15 | <Domenic> | hmm that's true |
| 19:01 | <wanderview> | Domenic: how does giving up .text() on partially read streams help here? |
| 19:02 | <Domenic> | wanderview: no idea, but yhirano_ was asking about it, so I thought I'd put it on record. |
| 19:02 | <wanderview> | Domenic: I guess we could have the .body getter set bodyUsed... but thats a little overeager! |
| 19:02 | <Domenic> | wanderview: that was kind of what I was thinking with sane-mode... would rather it be a function in that case. |
| 19:03 | <Domenic> | Although 43 shipped today so I can't imagine Chrome would be happy with that change |
| 19:04 | <Domenic> | (hmm, I should probably be celebrating, now that I think about it...) |
| 19:04 | <wanderview> | seems someone should be able to do var reader = s.body.getReader(); reader.closed.then(itsclosedjim); reader.releaseLock(); without forcing bodyUsed to true |
| 19:04 | wanderview | wonders why .closed promise is on the reader instead of the stream... |
| 19:04 | <Domenic> | hmm |
| 19:05 | <Domenic> | *that* was for GC reasons, I am 100% sure |
| 19:05 | <wanderview> | ok |
| 19:05 | <wanderview> | does the .closed promise not resolve if you .releaseLock()? |
| 19:05 | <Domenic> | it is already resolved the moment the reader came into existence. |
| 19:06 | <wanderview> | Domenic: for a stream with actual content? |
| 19:06 | <Domenic> | no, sorry |
| 19:06 | <Domenic> | it will immediately resolve when you releaseLock() |
| 19:06 | <Domenic> | inactive readers act like closed streams |
| 19:07 | <Domenic> | still stuck thinking about " seems someone should be able to do" |
| 19:07 | <wanderview> | Domenic: so if I want to observe when the stream consumption is complete I need to do something like s.pipeTo(sink).getReader().closed.then(foo)? |
| 19:07 | <Domenic> | what if ... bodyUsed was set to true for empty streams (as well as drained ones). But, putting GET requests didn't care about bodyUsed? |
| 19:07 | <Domenic> | wanderview: s.pipeTo(sink).then(foo) |
| 19:08 | <wanderview> | Domenic: I guess I'm trying to see how the .closed promise is useful if you can only use it when you are the sole reader... |
| 19:08 | <Domenic> | that's true |
| 19:08 | <Domenic> | it might be vestigial at this point :-S |
| 19:09 | <Domenic> | well, not quite |
| 19:09 | <wanderview> | Domenic: the other problem I see with setting bodyUsed in .body getter or a .body()... now you can't check for body null without triggering bodyUsed |
| 19:09 | <Domenic> | even if you are the sole reader it is quite useful for getting consolidated error notifications for example |
| 19:10 | <wanderview> | yea... some use... just not what I expected when I saw it in the API |
| 19:10 | <wanderview> | I thought it was an external observer |
| 19:10 | <Domenic> | it was but then GC concerns forced it into hte background. we reasoned we could add it back later. |
| 19:10 | <Domenic> | s/into hte background/solely into the reader/ |
| 19:10 | <wanderview> | it can also be manually added with a Transform that you pipeThrough() |
| 19:11 | <wanderview> | an ObserverTransform |
| 19:11 | <wanderview> | or whatever |
| 19:11 | <Domenic> | true |
| 19:11 | <Domenic> | and if that's author-space it shouldn't have GC issues |
| 19:11 | <Domenic> | maybe we can add it back |
| 19:12 | <Domenic> | OK what if we modified my proposal from https://github.com/yutakahirano/fetch-with-streams/issues/37#issuecomment-103584177 to not error for GETs |
| 19:13 | <wanderview> | well... HEAD OR GET |
| 19:13 | <Domenic> | so that would mean fetch(new Request(url, { body: "", method: "POST" })) fails, hmm. seems not great |
| 19:13 | <Domenic> | yeah |
| 19:13 | <wanderview> | but can't other methods optionally have bodies or not? |
| 19:13 | <wanderview> | like PUT and POST |
| 19:13 | <Domenic> | yeah. |
| 19:13 | <wanderview> | I think I prefer the wrapper |
| 19:13 | <Domenic> | I guess we could do the thing you were suggesting and translate empty body to null body |
| 19:13 | <Domenic> | wrapper sounds so heavyweight, but, maybe it is ok. |
| 19:13 | <Domenic> | i still think the overall story here is bizarre |
| 19:14 | <Domenic> | i.e. what we tell developers |
| 19:14 | <Domenic> | "sometimes you can multi-fetch, sometimes not. if you read the body to the end you cannot multi-fetch, but if the body was empty in the first place you can." etc. |
| 19:14 | <wanderview> | Domenic: the problem with special casing "" is that it won't work if a ReadableStream is passed directly as the body: new Request(url, { body: streamThatMaybeHasData }); |
| 19:15 | <Domenic> | ah right |
| 19:15 | <wanderview> | Domenic: I agree its a bit awkward... its a consequence of us not wanting to do implicit clone |
| 19:16 | <wanderview> | Domenic: what do you think of a just wrapping the inner source? fetch inserts an inner source wrapper into the body stream... once it gets its "a byte was read" state info then it removes its wrapper from the chain |
| 19:16 | <wanderview> | removing itself could be an implementation optimization |
| 19:16 | <Domenic> | code? |
| 19:17 | <wanderview> | Domenic: it would have to work on the inner concepts of the stream... is there a way to refer to the inner source in code currently? |
| 19:17 | <wanderview> | this would not be something we would let normal script do, I think |
| 19:17 | <Domenic> | wanderview: no, there is not... it's the same kind of layering violation I currently see in Blink I guess, is what you're suggesting. |
| 19:17 | <wanderview> | Domenic: to be honest, in gecko I would probably just stick a boolean "ever got data" into a private stream slot and let the DOM code inspect it |
| 19:18 | <wanderview> | I think thats the cheapest, simplest solution |
| 19:19 | <Domenic> | this is making me sad |
| 19:19 | <Domenic> | "it won't work if a ReadableStream is passed directly as the body" what if we say that always errors |
| 19:19 | <Domenic> | (if the ReadableStream is closed) |
| 19:19 | <Domenic> | we could let "" error too |
| 19:20 | <Domenic> | only null bodies work for multi-fetch |
| 19:20 | <Domenic> | seems conceptually closer to how things actually work |
| 19:20 | <Domenic> | you can only multi-fetch when you truly have no body |
| 19:20 | <Domenic> | is what we're trying to enforce here |
| 19:20 | <Domenic> | we shouldn't have a loophole for empty bodies |
| 19:20 | <wanderview> | Domenic: I think that creates a bit of the quantum streams problem for a pipe passed as the body... for example, if you consume the stream before pipe writer end is closed, then it works... but if the pipe writer end decides its done and no data was ever written, then now the body can't be used |
| 19:21 | <wanderview> | Domenic: I like that, except for the problem were passing "" errors without ever being usable |
| 19:21 | <Domenic> | "" erroring seems OK |
| 19:21 | <Domenic> | don't use body: "", use body: null. |
| 19:22 | <Domenic> | *or*, just clone defensively, if you're unsure. |
| 19:22 | <wanderview> | it would break backward compat... I guess we would have to special case "" for all the previously existing body initializers |
| 19:22 | <Domenic> | Let me try to write this up in a bit more detail so we can tear it down more comprehensively. |
| 19:23 | <wanderview> | Domenic: can "" be expressed for FormData or URLSearchParams? |
| 19:23 | <wanderview> | Blob has .size |
| 19:23 | <wanderview> | I think BufferSource has .length |
| 19:24 | <wanderview> | I guess for FormData and URLSearchParams we can just take the size of the resulting encoded value... they both run serializers... if the encoded value is length 0 then set body to null |
| 19:24 | <Domenic> | Is breaking back-compat there an option? How many people are doing multi-fetch with an empty FormData? |
| 19:30 | <wanderview> | Domenic: I think we can special case all of those to set a null body when empty |
| 19:30 | <wanderview> | Domenic: and the new ReadableStream body functions with the closed-is-drained semantics |
| 19:31 | <wanderview> | Domenic: I think that works for most cases... pipe might get a bit ugly as I mentioned above |
| 19:31 | <Domenic> | hold on, I appear to be reinventing the bodyUsed flag... |
| 19:31 | Domenic | goes to re-read the thread |
| 19:33 | <Domenic> | yes, I have begun re-inventing plan(X), as it is called. Nevermind... |
| 19:34 | <wanderview> | Domenic: I don't think thats the same as plan(X)... I don't think plan(X) equated stream closed with bodyUsed |
| 19:34 | <Domenic> | yeah, I was trying to do a different version that allowed you to fetch() once. |
| 19:34 | <wanderview> | basically we want to define bodyUsed as `.body && .body is closed` |
| 19:34 | <wanderview> | oh, ok |
| 19:36 | <wanderview> | Domenic: wait a minute... how can Response or Request tell if .body is closed initially? do they have to do a .read() and keep track to see if done:true is returned from the first .read()? |
| 19:36 | <Domenic> | yes |
| 19:36 | <Domenic> | that seems problematic for .bodyUsed |
| 19:36 | <Domenic> | Not problematic for actual consumption code |
| 19:36 | <Domenic> | but problematic for .bodyUsed. |
| 19:36 | <wanderview> | Domenic: what if its not closed... and it gets a chunk back... it can't push it back... |
| 19:36 | <wanderview> | I think we need a sync attribute to tell if closed or not |
| 19:36 | <Domenic> | then it continues consuming |
| 19:37 | <Domenic> | no need to push it back |
| 19:37 | <wanderview> | Domenic: well, I mean for for .bodyUsed which is itself not a consumer |
| 19:37 | <Domenic> | yes, .bodyUsed is problematic. |
| 19:38 | <Domenic> | I think it would need a sync getter, you are right |
| 19:38 | <Domenic> | why is this so hard -_-. doesn't feel like it should be. |
| 19:38 | <wanderview> | I think it would be useful anyway for devs to be able to inspect the state without potentially modifying the stream |
| 19:38 | <wanderview> | which was one of the reasons we added .bodyUsed |
| 19:39 | <Domenic> | i like how all access is gated on the reader and on being async |
| 19:39 | <Domenic> | but it's not essential i guess |
| 19:39 | <wanderview> | Domenic: this sort of thing would probably take an order magnitude less time if we were all in the same room with a whiteboard |
| 19:39 | <Domenic> | just seems nice |
| 19:39 | <Domenic> | heh, that's fair. |
| 19:40 | <wanderview> | Domenic: you could make it .body.getReader().state or whatever... so still gated on the lock |
| 19:40 | <Domenic> | sure |
| 19:41 | <Domenic> | i guess part of the mismatch here is that streams expects trying to consume a consumed stream to be a no-op |
| 19:41 | <Domenic> | whereas serviceworker and friends expect it to throw |
| 19:42 | <Domenic> | or reject i guess |
| 19:42 | <Domenic> | streams is not necessarily better when I put it that way |
| 19:44 | <Domenic> | right. and service worker has the sync "will this fail" getter in bodyUsed |
| 19:44 | <Domenic> | so if we want to translate between the streams model (or even if we were to change the streams model to also be a fail) we'd need a "will this no-op" getter on streams. |
| 19:45 | <Domenic> | i guess the motivation is higher in service worker land because failing is something you want to avoid more actively than no-oping |
| 19:45 | <Domenic> | so a bodyUsed getter is more important than a closed getter. |
| 19:45 | <Domenic> | (ugh, boolean adjective getters vs. past-tense promise getters... English is screwing us.) |
| 19:46 | <Domenic> | (I guess it'd be a state getter so crisis averted) |
| 19:46 | <wanderview> | Domenic: I guess I would propose a .state getter vs calling it .closed |
| 19:46 | <wanderview> | yesa |
| 19:46 | <wanderview> | yea |
| 19:47 | <Domenic> | ok i remember now why it's a no-op for streams instead of an error. because you never know if the next read() is going to be "oh actually i have no more chunks for you." |
| 19:47 | <Domenic> | So .read() cannot reject on stream end because it's non-exceptional |
| 19:47 | <Domenic> | But I can understand why readToEnd(stream) rejecting on stream being empty might be exceptional |
| 19:48 | <Domenic> | i'm feeling a bit better as i talk myself through this, hope you don't mind :) |
| 19:48 | <wanderview> | np |
| 19:55 | <wanderview> | Domenic: you see this? https://twitter.com/yaypie/status/600738702038409216 |
| 19:58 | <Domenic> | no, no idea what that's about. |
| 19:58 | <Domenic> | i'm tempted to blame user error until he gives more details; we have plenty of tests for concatenated minified JS. |
| 19:59 | <caitp-> | in 2015 bugs get filed on twitter instead of where people can find them |
| 19:59 | <Domenic> | wanderview: posted new proposal based on our discussions. i imagine it will need a few more tweaks... |
| 20:00 | <wanderview> | thanks, I'll take a look |
| 20:01 | <wanderview> | wow... I opened the email notification in gmail... and the github page was smart enough to take the (1) notification thing out of its tab name |
| 20:01 | <Domenic> | O_O |
| 20:03 | <TabAtkins> | Tracking images, yo. |
| 20:07 | <wanderview> | Domenic: I know you don't like my "quantum streams", but I think part of the mismatch we get between SW "fail on consumed streams" and the streams closed concept is that "consumed" implies that someone did something to the stream... I think its weird conceptually for a stream to become consumed on its own spontaneously (from initially empty or the writer |
| 20:07 | <wanderview> | end of a pipe being closed, etc) |
| 20:08 | <Domenic> | Yes. I don't understand that part of SW honestly, which is what this new thing is trying to fix. Why would a respones the server made empty be any different from one the developer made empty? |
| 20:10 | <wanderview> | not sure I understand what you mean by server/developer in this case |
| 20:11 | <wanderview> | to me "consumed" conceptually requires a consumer to take an action on the stream... even if it ends up a no-op |
| 20:12 | <Domenic> | I don't think consumed is a coherent concept |
| 20:12 | <Domenic> | It causes global coordination problems |
| 20:12 | <wanderview> | Domenic: can you elaborate on those problems? |
| 20:12 | <Domenic> | I give you an empty string from one part of the program. Have I consumed it yet, or not? |
| 20:12 | <wanderview> | to be clear, I don't think "consumed" is a replacement for "closed" |
| 20:13 | <Domenic> | It implies people should take different paths depending on what's happened in the past, instead of just working with what they're given in their part of the program |
| 20:13 | <TabAtkins> | Can there be something like iterator's "done" flag? An iterator might be empty at any point, and may or may not have indicated it yet, but once it's emitted "done", it's absolutely done. |
| 20:14 | <wanderview> | TabAtkins: yea... thats the kind of semantics I was expecting |
| 20:14 | <Domenic> | TabAtkins: we have that, it's closed. But service worker wants something different. |
| 20:14 | <wanderview> | or not |
| 20:14 | <Domenic> | Service worker wants "has anyone ever iterated over this iterator" |
| 20:15 | <Domenic> | which I maintain is a very strange way of programming |
| 20:15 | <Domenic> | You should work with the thing you're given, and its current state. Who cares how it got that way. |
| 20:17 | <TabAtkins> | Domenic: Oh yeah, they just want an exclusive stream. |
| 20:18 | <TabAtkins> | I mean, single consumer makes sense. |
| 20:18 | <Domenic> | they have that... they want to be sure nobody ever read it to the end and then decided they were ready to release access to its dead husk |
| 20:18 | <Domenic> | They don't like dead husks |
| 20:19 | <Domenic> | Hmm we could get rid of auto-release-on-close... and in fact not allow release of closed streams?? |
| 20:19 | <Domenic> | then no dead husks should be accessible |
| 20:19 | <TabAtkins> | Unless, like, you tee it and hand off one of the copies. |
| 20:23 | <wanderview> | Domenic: in fairness, the proposed spec explicitly did the "release access to its dead husk" in the .text()/etc methods |
| 20:28 | <wanderview> | Domenic: what is the use case for releasing the lock anyway? |
| 20:29 | <Domenic> | wanderview: once the stream is closed? not too much of one. You can contrive some ideas though. |
| 20:29 | <wanderview> | Domenic: I meant ever all unlocking... even while the stream is open |
| 20:29 | <Domenic> | wanderview: allowing multiple consumers access to different parts of the stream, e.g. headers, body, trailers |
| 20:30 | <Domenic> | readHeaders(stream).then(headers => readBody(stream).then(body => [headers, body])) |
| 20:30 | <Domenic> | readHeaders acquires and releases a lock |
| 20:31 | <wanderview> | Domenic: and what would this case do if there were headers and no body... the stream closed and left the lock in place... what would readBody() do? |
| 20:31 | <wanderview> | with your proposal |
| 20:32 | <Domenic> | wanderview: yeah I think it would have to check .locked first... or .state === "closed"?? |
| 20:32 | <Domenic> | failing though seems like a reasonable default tbh |
| 20:33 | <Domenic> | that code seems to expect a body |
| 20:34 | <wanderview> | Domenic: so an initially-empty stream would start in the state === 'closed' state, but not be locked... then someone could do getReader().read(), which would return done:true and leave the stream locked |
| 20:34 | <Domenic> | yeah i think that's the gist of it... |
| 20:34 | <wanderview> | Domenic: so bodyUsed would be `body !== null && body.state !== 'readable' && body.locked` |
| 20:35 | <Domenic> | sounds right |
| 20:35 | <wanderview> | Domenic: this brings us back to the original proposal modulo the "can't unlock a consumed stream" thing |
| 20:35 | <Domenic> | the difference being .locked reflects the current state of the stream instead of historical information about how the current state arose. |
| 20:40 | <wanderview> | Domenic: I think you can infer a lot by looking at state === 'closed' and locked attribute... if its closed, but not locked, then it was initially empty |
| 20:40 | <Domenic> | currently not true; currently state === 'closed' => locked === false always, because it auto-unlocks on close. |
| 20:41 | <wanderview> | Domenic: right, I meant with your proposal |
| 20:45 | <Domenic> | yeah |
| 21:03 | <roc> | philipj, Domenic: I tried filing a Chromium bug to get caretPositionFromPoint implemented (instead of nonstandard caretRangeFromPoint) but it didn't work out too well: https://code.google.com/p/chromium/issues/detail?id=388976 |
| 21:04 | <roc> | is there a better path? |
| 21:05 | <Domenic> | oof, that looks like some triage went wrong. I am not a veteran of the best procedures for such things but will ask around... philipj probably is such a veteran. |
| 21:07 | <roc> | thanks |
| 21:14 | <TabAtkins> | I'm trying to log into my chromium.org account, but it's fine to just put that back as Available. |
| 21:14 | <TabAtkins> | That's def the worst triage I've ever seen. roc, plz ping if you ever get service that bad. |
| 21:14 | <roc> | oh, I've seen worse :-). Thanks |
| 21:15 | <Domenic> | chromium.org accounts. the worst. |
| 21:15 | <roc> | are they volunteers? |
| 21:15 | <Domenic> | no I just meant having separate google accounts to use for chromium is the worst. I dunno about the triagers. |
| 21:50 | <philipj> | roc: is Gecko the only engine to implement caretPositionFromPoint so far? |
| 21:51 | <philipj> | looks like IE doesn't implement caretPositionFromPoint or caretRangeFromPoint, and WebKit/Blink only the latter |
| 22:25 | <roc> | philipj: I guess so |
| 22:26 | <roc> | philipj: I suppose we could revert the spec to caretRangeFromPoint if you think that's best. You should talk to zcorpan about it |
| 22:27 | <philipj> | roc: I suppose you don't have any metrics for how often caretPositionFromPoint is used? |
| 22:28 | <roc> | if we're the only browser with it, I'm guessing it's unused |
| 22:28 | <roc> | could be wrong |
| 22:28 | <roc> | so yeah, no data |
| 22:28 | <philipj> | caretPositionFromPoint is a less strange API, I can see why it was changed |
| 22:31 | <caitp-> | good job whoever fixed qSA + camelcased elements/attributes :d |
| 22:31 | <philipj> | I'll start a search in httparchive to see how caretRangeFromPoint is actually used |
| 22:44 | <Domenic> | TabAtkins: where's that spec where you were writing things in JS? colors maybe? |
| 22:45 | <TabAtkins> | Domenic: Yeah, color 4 |
| 22:45 | <Domenic> | Found it. |
| 22:45 | <Domenic> | V8 extras candidate \o/ |
| 23:04 | <TabAtkins> | Domenic: ??? |
| 23:05 | <Domenic> | TabAtkins: https://groups.google.com/forum/#!topic/v8-users/D6FmTwlvCgk people asking for a design doc, I'm writing one, was looking for examples of where V8 extras would be a good strategy, color API is definitely one. |
| 23:06 | <TabAtkins> | Ah, cool. |