Confusing integration with Fetch API

[tete17]

What is the issue with the Fetch Standard?

The standard makes very ambiguos calls in Section 4.

It claims a websocket have certain patterns like "message received" or "connection close" which allogin more with the RFC spec but it then uses the Fetch API to "establish a connection".

As far as I know there is no way for a fetch api to continue sending data or to customize the way data is send.
It makes it very confusing to read as you are not sure what is the right approach.

[annevk]

I'm sorry, but I don't really understand the issue you are trying to raise. Generally nothing integrates with the Fetch API directly and the Fetch API itself is just a thin layer on top of "fetch", which is indeed quite big and at times vague.

And while Fetch had a bit more to say about WebSockets in the past as noted at https://fetch.spec.whatwg.org/#websocket-protocol, it no longer does (except for some very specific code paths).

[tete17]

Sorry I didn't express myself very well.

My problem while trying to implement the standard in Ladybird is that the wording in section 2.2 Opening handshake makes it sound like Websocket is implemented on top of the Fetch as step 11 says: Fetch request with useParallelQueue set to true, and processResponse given response being these steps:`

To me this sounds like I we should based our Websocket implementation around the Fetch api calls but it can't be right as it has no mechanism to send extra data like Webhooks should.

The part that confuses me is that reading part of the spec I get the feeling the Webhook Class should have a private member class that implements the webhook protocol at the network level but it should use Fetch apis at the same time.

I hope I have made my concern a bit more clear

[annevk]

The idea is that the WebSocket connection comes out of the same connection pool indeed (these are unrelated to the Fetch API though, that's a very specific section in the Fetch standard which only exposes a subset of what fetching is capable of). The WebSocket handshake is also just a fetch.

Is part of the problem that you are confusing what fetch() (the API) is capable of and what "fetch" (the concept) is capable of?

[tete17]

May very well be.

I though the Fetch api was just the implementation of the concept of a fetch but your wording seems to suggest I am wrong.

I am still very new to this world :)

[tete17]

I also only realized I created the issue in the fetch standard rather than in the Websockets one where this really belongs...

[annevk]

I was wondering about that. I moved it. I think WebSockets is hard to read because there's the RFC that's being patched to some extent by the WebSockets API standard. The RFC really needs a rewrite, but nobody has been interested in taking that on.