Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: curl websockets
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Weston Schmidt via curl-library <curl-library_at_cool.haxx.se>
Date: Wed, 23 Jun 2021 14:40:50 -0700
> 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
Received on 2021-06-23
Date: Wed, 23 Jun 2021 14:40:50 -0700
> 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
Received on 2021-06-23