| 05:32 | <annevk> | Oh lgrahl left. I was gonna point out that these are the same people that initially passed on promises. I hope they won’t make that mistake again… |
| 08:08 | <annevk> | hsivonen: really glad we got that blame setup for the HTML Standard btw |
| 08:08 | <annevk> | hsivonen: already traced back many things |
| 08:08 | <annevk> | hsivonen: and much quicker than calculating it locally |
| 11:41 | <gabri> | Good morning/evening, I'm currently writing my bachelor thesis on service worker and progressive web apps. I'd like to write a small historic introduction of the steps that lead to the current ServiceWorker definition by the W3C and so I discovered the existance of WHATWG ( people outside doesn't know you exist). Can someone share to me some resource of the Web Workers definition story? Did W3C used some part of them to define Service W |
| 11:43 | <surma> | @gabri: You can find an extensive history in the repository of the spec: https://github.com/w3c/ServiceWorker |
| 11:43 | <surma> | It’s not necessarily easy to consume, but if you look at older/closed issues and the discussions therein, you should find a lot of interesting information |
| 11:44 | <surma> | Stream spec: Is there anything speaking against turning `controller` in the note here into a link? I often find myself looking up how to define an `underlyingSource` and then having no link to the definition of controller in the vicinity. https://streams.spec.whatwg.org/#rs-constructor |
| 11:45 | <gabri> | thank you @surma |
| 11:50 | <annevk> | ricea: ^^ question about streams |
| 11:53 | <annevk> | gabri: workers were inspired by Google Gears; see https://lists.w3.org/Archives/Public/public-whatwg-archive/2008Jul/0110.html for one of the earlier messages summarizing the initial addition |
| 11:59 | <annevk> | foolip: so I'm almost never having problems with the build script anymore |
| 11:59 | <annevk> | foolip: adding retry seemingly helped |
| 12:00 | <annevk> | Whenever it fails now it's just my mistake |
| 12:00 | <foolip> | annevk: huh, which bit are you guessing was failing before? |
| 12:01 | <annevk> | foolip: curl for bikeshed was failing every now and then |
| 12:01 | <annevk> | foolip: I added https://github.com/whatwg/whatwg.org/commit/0db31edad82b56f6419fc555fb9c2d334db7bc16#diff-e9607901cbff22c83689e88cb1c1eca6 and haven't seen it since |
| 12:03 | <foolip> | Ok, so Bikeshed. Well, I guess retry is the way of reliability when networks are involved, even though it feels icky |
| 12:03 | <foolip> | I never feel icky about whatever TCP does though :) |
| 12:05 | <annevk> | Well, curl for whatwg.org fails sometimes too, but that I cannot patch in the build script |
| 12:05 | <annevk> | Would have to patch each caller and it hasn't happened a lot recently so I'm not too bothered |
| 12:05 | <annevk> | And yeah, it's bugs all the way down and up |
| 12:11 | <lgrahl> | annevk: Read your last message in the log. Yeah, what can I say... it's not easy to convince these people. |
| 12:12 | <annevk> | lgrahl: I added a comment on the issue that I hope helps |
| 12:12 | <annevk> | lgrahl: but my understanding of WebRTC is not great... |
| 12:12 | <lgrahl> | Yeah, thanks. I was too tired of it yesterday to add anything. |
| 12:17 | <lgrahl> | At least API-wise it's not great. |
| 12:19 | <lgrahl> | I have a quick question for the Fetch API: IIRC one sends a HTTP request and gets a body mixin as soon as the header of the response has been received. And then one can choose in what kind of data format they want to have it. Is that correct or have I missed something? Disclaimer: I haven't read all of it. |
| 12:21 | <annevk> | lgrahl: reading the backlog, a blob provides async access to fixed-size memory (sometimes backed by a file, if the file is changed, the blob will error); given the way a blob is allocated though you cannot really do it before you have all the bytes (arguably maybe you can if you know the size upfront, but that would be new thing of sorts and probably require |
| 12:21 | <annevk> | significant impl work) |
| 12:21 | <annevk> | lgrahl: once you have all headers, yes |
| 12:22 | <annevk> | lgrahl: and yeah, you can pick between "read all bytes as X" and "gimma the stream" |
| 12:22 | <annevk> | (at that point) |
| 12:22 | <annevk> | back later, lunch |
| 12:25 | <lgrahl> | annevk: Right, so a Blob is essentially too high-level. It would be massive backpressure on the receiver side (one can argue about the sender side because at least theoretically a Blob could be read in chunks). Whereas a stream is high-level when possible and low-level when I need it. It also allows me to handle backpressure. |
| 12:29 | <lgrahl> | annevk: If there's anything else coming to mind where streams provide an advantage over Blob, let me know. Anything that helps to convince them. :) |
| 12:41 | <lgrahl> | annevk: Coming back to the body mixin... I think this would have been cool for WebSocket and data channels but it's probably too late for that. USVString for example is not something you can choose on the receiver side but rather the sender enforces it by sending one. I'd say streams are our best bet now. |
| 13:00 | <annevk> | lgrahl: why could you not make it possible to chose string/bytes on the receiver side? |
| 13:01 | <annevk> | lgrahl: it seems if you can enable streams, you can enable that too (not saying it's needed per se though) |
| 13:01 | <lgrahl> | annevk: Data channels (and I think WebSocket too) have some kind of type inside of a message that indicates whether the message is binary or USVString. |
| 13:02 | <annevk> | lgrahl: sure, HTTP has that too through Content-Type, but you can still do whatever |
| 13:03 | <annevk> | lgrahl: current API shape might be either/or, but that's not inherent I think |
| 13:04 | <lgrahl> | annevk: Sure. But it would be kind of confusing to have an API where you either get USVString or binary where you can choose between ArrayBuffer and Blob and (new) Mixin... which again would let you choose to use .text, .json, .blob, ... |
| 13:06 | <lgrahl> | It makes sense for us but will it make sense for them? :) |
| 13:07 | <annevk> | Yeah, that's probably not the way to go |
| 13:07 | <annevk> | lgrahl: the other thing to consider here is that the timing for the event would be different |
| 13:07 | <lgrahl> | In a revised API we should go for it. |
| 13:08 | <lgrahl> | Yeah, you mean when you switch between Blob and stream? |
| 13:08 | <annevk> | lgrahl: you might just want a new messagestart even or some such |
| 13:10 | <lgrahl> | It's not a big deal though as only one message can be received at a time per channel. It's just something API users need to be aware of but most of them will probably not even bother (because it's not really different in terms of usage). |
| 13:12 | <lgrahl> | So, unless I missed something, it would be fine to use 'onmessage' for that. Also, I'm not a big fan of event callbacks because they are hard to handle when you have plenty of them. |
| 14:44 | <gabri> | Good morning/afternoon. I'm the same as before asking for resources for his thesis. Now my question is about AppCache, I know it's deprecated but I'd like to have a clarification anyway. There are both W3C and WHATWG documents about this, who is the original proposer? If my questions annoy, tell me and I'll quit |
| 14:46 | <annevk> | gabri: https://github.com/whatwg/web-history might help |
| 14:47 | <annevk> | gabri: basically most things HTML5 originated at the WHATWG |
| 14:47 | <gabri> | This might be the right thing I'm looking for, thank you! |
| 16:41 | <wanderview> | yoav_: does preload cache in chrome/webkit sit above or below service worker interception? |
| 16:43 | <wanderview> | yoav_: I know its unspec'd... just curious what browsers are actually doing |
| 16:45 | <wanderview> | yoav_: I've been told it just hooks into memory cache... which I guess means it sits above service worker interception |
| 16:56 | <yoav> | wanderview: above |
| 17:01 | <lgrahl> | annevk: If a data channel's message would be a stream, I could pipe this directly into a HTTP request by using the fetch API and thus upload a large file efficiently, right? |
| 17:02 | <annevk> | lgrahl: yeah, in theory |
| 17:02 | <lgrahl> | annevk: And practice? :) |
| 17:03 | <annevk> | lgrahl: no impl for upload |
| 17:03 | <lgrahl> | annevk. Ah, okay. Are there implementations for Response so far? |
| 17:04 | <wanderview> | lgrahl: for Response I believe all browsers except firefox have implemented ReadableStream body |
| 17:05 | <wanderview> | firefox implementation is disabled behind a pref while a few issues are sorted out |
| 17:07 | <lgrahl> | wanderview: Okay, cheers! |
| 17:07 | <wanderview> | yoav: thanks |
| 18:24 | <annevk> | Domenic: if a constructor takes one optional argument, what is Interface.length? 0 or 1? |
| 18:33 | <annevk> | Looks like 0 based on FormData |
| 18:39 | <jyasskin> | surma: I don't own the Streams spec, but there's almost never a problem with more links. Send a patch against https://github.com/whatwg/streams/blob/master/index.bs#L439? |
| 18:40 | <surma> | jyasskin: Noice. Thanks! |
| 18:49 | <annevk> | surma: goes for structuredClone too btw |
| 18:50 | <surma> | annevk: Yes. Planning on tackling (and PR’ing) that in ~2 weeks. Have some travel for the next 2 weeks. |
| 18:52 | <annevk> | Cool cool |
| 18:53 | <TimothyGu> | surma: you might be interested in the fact that structured cloning with V8 is indeed faster than JSON.parse(JSON.stringify()). Node.js exposes some lower level bindings to V8 |
| 18:54 | <TimothyGu> | 's serializer/deserializer, and you can test that with v8.deserialize(v8.serialize(obj)). |
| 18:54 | <TimothyGu> | v8.serialize() returns a Buffer (a Uint8Array subclass) though, and if you convert that to a string then JSON is still faster |
| 18:56 | <surma> | TimothyGu: That’s super interesting, considering that I haven‘t found any way to be faster than JSON.* in a browser environment |
| 18:57 | <TimothyGu> | not by much really, but still some |
| 18:57 | <surma> | Well, even if it’s only a tiny bit faster, it’s win considering it’s more flexible/powerful. |
| 18:58 | <TimothyGu> | Good point. |
| 19:15 | <annevk> | So in Node.js the serialization format is exposed? o_O |
| 19:53 | <annevk> | surma: we currently use an HTTP API for Bikeshed; I don’t really know if switching to Docker would end up using less resources… |
| 19:54 | <surma> | annevk: I wasn’t trying to replace the HTTP API. But if you wanna build offline and don’t want to bother with setting it up, it might come in handy. No worries if you just wanna ignore the entire thing. I mostly built it for myself :) |
| 19:55 | <annevk> | surma: I might look into it since I had some issues last I looked into it, but I’m mostly happy just using Travis et al |
| 19:55 | <surma> | It might also be nice to lower the barrier to entry to spec work |
| 19:56 | <surma> | If people want to play around with BS and figure out the syntax, they can just dive in straight away |
| 21:02 | <Domenic> | Well, if they have Docker knowledge and installation |
| 21:57 | <surma> | Domenic: Installation, yes. Knowledge, not really. You literally copy-paste the command from the readme. It will download the image automatically if necessary. But yes, installing docker would still be required. |
| 21:58 | <surma> | TabAtkins: I am building the stream spec and it seems `<emu-alg>` is not being processed properly. Is that a problem in my setup or is that a stream spec special thing? |
| 21:58 | <surma> | TabAtkins: ^ That is a bikeshed question. |
| 21:59 | <TabAtkins> | Streams uses ecmarkup as well, which isn't part of Bikeshed quite yet. Domenic can tell you how to get that set up. |
| 22:00 | <jyasskin> | (https://bterlson.github.io/ecmarkup/) |
| 22:00 | <surma> | Thaaaaanks. |
| 22:33 | <surma> | \o/ My first WHATWG spec PR https://github.com/whatwg/streams/pull/872 |