Fill in more of README.md, add Luke Wagner to champions #51
Conversation
lukewagner
requested review from
PiotrSikora,
devigned,
Mossaka and
danbugs
Add Phase 4 Advancement Criteria
I'm obviously supportive, since you've been doing all the work in this repo, but doesn't the process require the group to vote on this in the meeting? |
|
The process for adding champions is just to have the consent of the existing champions - no vote or subgroup meeting is required. |
|
|
||
| WASI-http must have at least two complete independent implementations. One | ||
| implementation must execute in a browser and may be implemented in terms of the | ||
| [Fetch API] using JavaScript. The other implementation must be implemented |
There was a problem hiding this comment.
Good question. The Fetch API (specified here) is for outgoing requests, but you're right that FetchEvent is also necessary for incoming requests, and I think they're in the Service Worker spec (here), which is separate. So I guess a fix would be to mention FetchEvent in addition to the Fetch API, linking to the SW spec, if that sounds right to you.
There was a problem hiding this comment.
Hopefully those browser APIs mirror each other and there is no surprise. Maybe linking both it the right thing to do.
There will be interesting details about streaming behavior of request and response. I know that not all browsers implement streaming in fetch. They buffer first until they have full body. Only Chromium knows how to stream.
And I don't know that is also true for service worker.
That said, maybe this WASI api could consider those details.
I guess other implementers may have similar limitations.
Also aborting, timeouts and canceling of promises is interesting in this context (in order to safe bandwidth and/or memory when you don't need the data anymore). Browsers implement those gradually ...
Sorry I have not looked at this WIT yet.
This PR also adds me to the list of champions, hence my request for approval from the existing champions. The PR also fills in more of README.md, better aligning it with the WASI template. Lastly, I merged
incoming-handler.wit/outgoing-handler.witintohandler.witsince now that's easy in Wit and it seems convenient to be able to read them in juxtaposition.As next steps, in preparation for Stage 2, I plan to:
errorin terms of RFC 9209 #49, replacing the other TODO intypes.wit(which I believe is the last obviously-missing part of the proposal)