| 09:53 | <Domenic> | Any reason html.spec.whatwg.org is not CORS-able? |
| 12:17 | <JakeA> | I'm enjoying this "HTML6" email already. Not only for the HTML6, but the assertion that javascript frameworks render in 10-50ms |
| 12:33 | <espadrine> | He may be talking about switching from one "subpage" of the SPA to another |
| 13:14 | <JakeA> | true |
| 13:50 | <wanderview> | Domenic: if I've already done the work to make our Response.clone() do a zero-copy tee of the underlying body stream... there is nothing in the current proposal that would stop me from using it right? I would not have to de-opt for some reason? just concerned that the tee() always makes a new stream will force that on me |
| 13:50 | <wanderview> | I think I could use wrappers to keep the same underlying stream |
| 14:11 | <wanderview> | Domenic: based on what you wrote in the github issue, this tweet should really say res.body.getReader().read()? https://twitter.com/domenic/status/578002598487175168 |
| 14:11 | <wanderview> | not to be pedantic... |
| 14:12 | <wanderview> | but it seems people care about the details |
| 14:33 | <Domenic> | wanderview: yeah, good point, can't believe I missed that :-/ |
| 14:34 | <Domenic> | wanderview: and yeah definitely no reason to de-opt. zero-copy is always the goal. |
| 14:35 | <wanderview> | Domenic: I think I convinced myself the zero copy is not a concern with shared ArrayBuffer chunks... might be more a concern when ReadableByteStream appears |
| 14:38 | <Domenic> | yeah, ReadableByteStream is an interesting tradeoff, for sockets at least. If there are chunks in user-space that are too large, but then the consumer requests like 10 bytes, either you have to do some C++ magic to make an ArrayBufferView onto a 10-byte-subset, or you have to do a copy. |
| 14:38 | <Domenic> | Yet, it gives the consumer complete control over allocation, so as to avoid any GC and allow buffer re-use and such |
| 14:39 | <Domenic> | And, for files, where it can connect directly to read(2), it should work beautifully |
| 15:32 | <JakeA> | Domenic: https://code.google.com/p/v8/issues/detail?id=3237 makes me sad. Any idea why making APIs up and shipping them is somehow ok in thuis case? |
| 15:32 | <JakeA> | this* |
| 15:32 | <Domenic> | JakeA: no idea at all. It's absolutely horrible. |
| 15:32 | <Domenic> | My only guess is that the V8 team doesn't have to follow the normal process? |
| 15:33 | <JakeA> | sadface |
| 15:36 | <beverloo> | they're indeed outside of the process |
| 15:37 | <beverloo> | although more recently they've been sending intent to ship/PSAs, which already is a step forward :) |
| 15:41 | <JakeA> | Hopefully we can get them to remove those APIs. It's kinda shitty |
| 15:41 | <JakeA> | By "kinda" I mean "absolutely and totally" |
| 17:19 | <JakeA> | annevk: getting more requests for status code on opaque requests. Going to start looking at it again, perhaps if credentials are omitted. Agree it's contentious though. |
| 17:19 | <JakeA> | Chrome doesn't allow fetch('//other-origin', {mode: 'no-cors'}) from a window, which doesn't make sense to me |
| 17:20 | <annevk> | I think that's only disallowed because they couldn't come up with a use case and don't support cache in window? |
| 17:20 | <annevk> | JakeA: credentials are not the problem. I recommend reading https://annevankesteren.nl/2015/02/same-origin-policy |
| 17:21 | <annevk> | Well, they are part of it, but mostly it's firewalls. |
| 17:25 | <JakeA> | annevk: it's disallowed because it exposes the existence of a server. Which is weird because it's somehow ok in a SW, and you can use img requests to /favicon.ico to detect servers anyway |
| 17:26 | <JakeA> | Great article btw |
| 17:26 | <annevk> | JakeA: when I mentioned that I thought that was bullshit someone on blink-dev told me it was because of the reason I just mentioned |
| 17:26 | <JakeA> | hm, that's not what I was told, but maybe I got the info 2nd hand |
| 17:39 | <beverloo> | annevk, any concerns with changing Notification.close() to return a promise? |
| 17:39 | <beverloo> | annevk, in short, it could be asynchronous and may cause unexpected behavior if SWR.getNotifications() is called immediately afterwards |
| 17:40 | <beverloo> | it'll also allow us to reject if it's already closed. none of this should impact current users of the API. I'll write a PR in a bit |
| 17:40 | <JakeA> | beverloo: better to resolve with a boolean if it's already closed |
| 17:41 | <JakeA> | As in, resolve with true if something actually changed, false if it was already closed |
| 17:41 | <beverloo> | closing something that's already closed feels like an exception to me? |
| 17:41 | <beverloo> | happy to go either way |
| 17:41 | <annevk> | beverloo: I think my concern would be that getNotifications() doesn't necessarily take close into account |
| 17:41 | <annevk> | beverloo: as per the specification that is deterministic |
| 17:42 | <TabAtkins> | beverloo: Unless there's a way to check whether it's closed, and a good reason to make double-closing an error, I wouldn't throw. |
| 17:42 | <annevk> | beverloo: closing might be racy |
| 17:42 | <annevk> | beverloo: so shouldn't throw, but I'm not really convinced yet this is needed at all |
| 17:42 | <TabAtkins> | (Python, for example, offers two set deletion functions, depending on whether you care about double-deletion or not.) |
| 17:42 | <beverloo> | ok, I'm convinced to use a boolean rather than reject |
| 17:42 | <beverloo> | for us, closing a notification will be asynchronous, and I imagine this will the case in other implementations as well |
| 17:43 | <annevk> | I mean that's fine, but you could schedule it in such a way that getNotifications still gets the right answer |
| 17:45 | <beverloo> | that's true, but I'd rather be explicit about the fact that it's not synchronous |
| 17:46 | <beverloo> | if people don't care they won't use the promise |
| 17:46 | <beverloo> | like today |
| 17:46 | <annevk> | Well it sounds like you want a promise to allow for racy behavior... |
| 17:47 | <annevk> | As that was your motivation rather than something about the developer wanting to know whether they already invoked close() before... |
| 17:48 | <beverloo> | hm. Neither are great arguments if we're honest :-). |
| 17:49 | <beverloo> | because of the way how we're implementing getNotifications it will work fine, but I just don't think it's clear |
| 17:49 | <beverloo> | it's not racy because of an implementation detail |
| 20:05 | <annevk> | beverloo: well so my argument is that it's already defined to be non-racy and that I haven't seen rationale for exposing closedness |
| 23:34 | <zewt> | (things to do before posting suggestions about html: know that there's no such thing as "html6") |