> On Jun 23, 2021, at 11:23 AM, Daniel Stenberg via curl-library > <curl-library@cool.haxx.se> wrote: > > On Tue, 22 Jun 2021, Weston Schmidt via curl-library wrote: > >> I'm interested in feedback or suggestions for what/how to define a good >> websocket API that complements libcurl. > > My very simple idea on how it could be added to the API: > > 1. We add another value to set CURLOPT_CONNECT_ONLY to (2). If this is used, > and the URL is "http(s)://" then libcurl could "bootstrap" into a websocket > connection. > > 2. Once it is completed, we could have the application extract the socket (to > have something to wait on) and then use curl_easy_recv() and curl_easy_send() > to receive and send websockets data over that connection. > > What would this be missing?
There’d be want, IMO, for interfaces that differentiate sending/receiving full messages versus per-frame. (And, of course, sending text versus binary, *maybe* flexibly enough to accommodate potential new message types were that ever to happen.) And callbacks for multi-mode? Also the data from the close frame would probably be available via some new CURLINFO_* constants? A couple other notes (having written a full WS library and a Perl binding for another): - curl_easy_recv() would need either to poll under the hood or to do a socket timeout so that curl could send a ping if the local ping timeout happens midway through the recv. - WebSocket compression is a per-message affair: one message can be compressed while the next is uncompressed. - WS compression is also tunable; ideally those parameters should be configurable. (More specifically: WS’ deflate compression is tunable; any future compression schemes would probably also be.) I’m excited to see this! cheers, -Felipe ------------------------------------------------------------------- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
