2023 WinterCG

WinterCG

• Date: June 6th, 2023
• Issue: https://github.com/Igalia/webengineshackfest/issues/14
• Slides: https://abotella.pages.igalia.com/wintercg-hackfest-2023/

Dan E.: what are the chances of wintercg fetch getting integrated into upstream fetch?

Anne: Depends on what modifications you want to upstream

Dan E: Right now it is a fork...

Luca: primarially around CORS, which is just in browsers. The changes are, if you are a serversside, don't do these things.

Anne: main worry is ongoing maintenance

Dan: that is a reasonable precondition....

Anne: I'm not sure if other within the WhatWG feel similarly. Currently, the way our working mode is structured, it is kind of tricky to have a conformance class... if we need sign off from multiple implementers, which are browsers. So this is a not browser implementation. We can either lift that, or the steering group needs to think about what to do

Luca: An actual change that effects web users should go through the working group requirements. but things which do not effect browsers, totally isolated to different conformance class (not implementing cors)

Anne: we can rely on the editor. Its non normative for now. If you want to make API additions that don't make sense for browsers... namespace issues. if browsers are ok with some names being used on servers and not in the web.

Andreu: For the Chromium Intent to Ship, I made the argument that you can have a proxy fetch in userland with Headers.prototype.getSetCookie

Anne: getSetCookie is everywhere. I was thinking of APIs that are not in the browsers anywhere

Dan E: (TODO missed something about wintercg preventing more of "x")

Anne: Once you have a redirect you hide the target - there is some translation that need to happen there

Luca: the whole concept of response codes, ok redirect, there is no reason for us (serverside) to have them. We could like fetch to not follow a redirect. Difference of policies in CORS might effect other parts of hte spec

Anne: that is not CORs

Dan: the same origin policy in general or cookie store

Anne: CORS is strictly about loosening the same origin policy

Andreu: devs complain about CORS, rather than about the same origin policy

Luca: if the error message said "same origin policy" we would not have this problem

Anne: right we are trying to be specific. maybe the error message should say 'there is no hope'

Andreu: Full-duplex is also something server-side runtimes implement but browsers have no interest in

Anne: when the server can respond with is response body before the request fully finishes "full duplex". Usually, full request body must be recieved. You need ot opt into half duplex for request streams to ever work. Full duplex is required to throw, because no browsers are interested in it.

Luca: but there is a carve out to potentially allow full duplex in the future.

Luca: a get set cookie that would be actually useful. Right now they need to use websockets.

Anne: browser are like, well, just do two fetchs to implement web sockets

Dan: that should be cheap enough

Luca: but now there is extra complexity (explains)

Anne: its not pretty

Dan: I don't understand use case?

Luca: imagine where there is a storage service, but the file is too big to fit in memory, and the server performs a transcoding, and you want to know how muhc has bene transcode. Streaming upload the file, streaming download status updates, this has to happen through websockets or two different fetchs. Right now the spec says the fetch must be complete before responding.

Anne: also you can say "stop" if something breaks, before the stream is finished

Luca: and you have to send a new fetch call to figure out why the server closed.

Anne: personally, I think this is a thing that browsers should be able to do, but hard to get prioritized

Luca: a lot of http implementations rely on this ordering. When does the error get returned. the possible error cases increases.

new topic

Dan: in bloomberg, we have a few javascript run times, some are more front endy and others more backendy. It makes sense for them to go to web interop env. We have talked to embedded folks in tc53, where they have javascript built in modules, avoiding promises and stuff.... it makes sense to have a lot of different run times that reproduce the same set of APIs. servers are similar enough to agree on things between them. For resourceful desktop, mos things are relevent to include

Andreu: nativescript doesn't use the dom. Bloomberg runtimes don't use the dom. There are some APIs that are useful for them but not server side?

Dan: At the moment, I'm interested in using more web apis outside the web, broadening this way. I don't think any adjustment needs ot be made for the runtimes I'm working with. you can't write an application just in wintercf....?

Andreu: that reminds that at some point, we should add the filesystem API, opfs.. more generic file system access. that could be added to the chromium API

Dan: I think wintercg should be focusing on things which are already multi-browser, which filesystem is now

Andreu: Since Request/Response can be used for server APIs, maybe the basic primitives for OPFS in the browser can be used for server-side filesystem

Luca: in the current filesystem api, everyhting needs a synchonous size. files on filesystem, when you open a file descriptor, it doesn't have a fixed size.

Anne: you are talking about file objects...

Luca: once you have a handle to a file, it assumes the size of the file does not change for the lifetime of the handle?

Andreu: I think parts of the API says if the file size changes, any actions will throw

Luca: a snapshot of size when you open. This is not useful for sqlite databates.... you open the file and grow and shrink it.. There is an iteration of the file system API for backing databases with granular reads and writes...

Anne: there are 4 or 5 filesystem APIs

Luca: there is a concept of a filesystem handle... (TODO: missed) there is not synchronous read write. Deno handles every usecase. You can get a snapshot of the size of the file with stat. I'm not happy with filesystem API.

Anne: you main problem with create sync access handle is only workers?

Luca: I want an async version with resizable files

Anne: I think this is slated for future versions

Dan: I feel like there is promise of (?) for webassembly, but webassembly has...

Luca: there is a benefit for sync APIs, for things like flushing. So you don't have to use lock. When you don't want an event loop.

Dan: (TODO: missed)

Luca: right now to do IO you need to spawn a new thread. node and deno do this.

Dan: you can use a different API. io_uring

Luca: not well implemented until recently

new topic Runtime tests

Andreu: we need a test suite, maybe a fork of WPT? Deno is using WPT, but only some

Luca: we can technically run html tests.....

Andreu: parsing html with an external library and running script elements

Dan: under what conditions can winter CG work on tests

Luca: in deno, we pull down the entirty of WPT. if we have to make a change, we upstream it. We try to run all the fetch tests, and the ones that succeed, we keep running, otherwise we put the ones we fail in an expectation file (like CORS) so we can ignore them

Andreu: it would make sense to port as many html tests to js tests as possible, as it makes it easier for other runtimes to run them

Luca: we have upstreamed a bunch of that work, and it revealed errors, because when they are js tests they can run in web workers and show bugs!

Dan: question for anne, which changes would you encourage people to work on?

Anne: I think these changes are generally good.I think the changes is to WPT are very good. but some concern about tests taking CI to run longer. Maybe we should constrain the nmber of env tests run in to cut down on time. I think we looked into running ecma262 in multiple envs, to see if there was weirdness in js runtime in worker, that didn't work out. hard ot run 262 to run in different host envs. largely it showed no difference. gecko for a long time has seperate hr implementations of workers.

Luca: its enough to run the idl harness in both. I assume most browsers don't implement headers twice.

Dan: in addition to performance, any other concerns?

Anne: no not really. WPT generally encourages people to contribute.

Dan: if we want to disable tests easily in a wintercg env, or provide alternative expectations, whats a good generic way?

Luca: we need to define these performace classes somewhere..

Anne: you should start an RFC proposal for this

Andreu: One thing I was thinking about is test files that relate to WinterCG, but have one specific test that requires something else. In Deno, there's no way to distinguish between browser-specific tests that are meant to fail, and tests that don't intentionally fail

Luca: goes along with performace class problem. We shouldn't mix in one file tests that mix performance classes.

Anne: generally resturcturing is file, just make sure you don't introduce regressions.