Why not follow existing proposals for Sockets API

[targos]

Hey, I'm sorry if this has already been discussed. I'm just wondering why an entirely new API is being designed when there is at least one existing proposal: https://wicg.github.io/direct-sockets/
Has it been considered to work with Google on that?

[dom96]

From what I recall there were concerns that this proposal wasn't going anywhere with objections from Firefox/Safari and others. @jasnell may be able to give more detail.

[saghul]

👋 I was considering folling this spec on my runtime (txiki.js) but it doesn't cover UDP, and it looks like Chrome is shipping direct-sockets in M131: https://chromestatus.com/feature/6398297361088512

Perhaps some alignment should be reconsidered here?

[dom96]

@saghul fwiw this spec is pretty close to the Chrome spec. The main difference is that the readable and writable property is inside the opened promise which prevents optimisation like pipelining (which our runtime takes advantage of). Really it would be good for the Chrome spec to adopt this.

[saghul]

The main difference is that the readable and writable property is inside the opened promise which prevents optimisation like pipelining (which our runtime takes advantage of)

Can you please elaborate on this? How does that optimization look like and how big is the improvement in practice?

Really it would be good for the Chrome spec to adopt this.

This proposal seems to have come 3 whole years after Chrome's first one, if I'm reading Git history right. Plus, it considers UDP.

I have no horse in this race, but as an implementor (and one who likes UDP!), direct sockets looks more appealing, because it's more complete and it's shipping in a browser with a wide adoption and usage.

[dom96]

This article has an explanation of this optimisation: https://blog.cloudflare.com/workers-tcp-socket-api-connect-databases/#start-writing-data-immediately-before-the-tls-handshake-finishes.

When we were implementing this it wasn't clear whether the Chrome proposal would ever be shipped in the browser. But yeah, in any case, the proposals are quite similar and we don't yet support UDP.