> 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?
This makes sense to me. In the present bolt-on solution I have the "streaming" interface via callbacks & then added a "block" based interface based on the streaming. I like having the flexibility to do either. :) > Also the data from the close frame would probably be available via some new > CURLINFO_* constants? That seems reasonable. > - 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. You bring up an interesting point that I don't have a good answer for - how should the easy interface work? I struggled with it when working on the curlws code & decided to avoid it in favor of the multi api. If there is a good example of something similar in curl as a pattern, that might help inform how to do it. Best, Wes > > - 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 ------------------------------------------------------------------- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
