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.
Request send back too
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: hendrik hellemons via curl-library <curl-library_at_lists.haxx.se>
Date: Tue, 21 Jun 2022 19:02:21 +0200
Message: 1
Date: Mon, 20 Jun 2022 21:58:59 +0000
From: Dmitry Karpov <dkarpov_at_roku.com>
To: Dmitry Karpov via curl-library <curl-library_at_lists.haxx.se>
Subject: RE: About a websockets write callback
Message-ID:
<
DM6PR01MB5611D2DB80A2A39FF84AEFA8C3B09_at_DM6PR01MB5611.prod.exchangelabs.com>
Content-Type: text/plain; charset="us-ascii"
Yes, it would be nice to have just one callback for all WS modes (RAW,
FRAME, MESSAGE) but using CURLOPT_WRITEFUNCTION callback for that purpose
doesn't seem like an optimal solution to me because of the problems related
to passing curl handle to it and making a function call to get WS context
metadata.
All WS levels above RAW (frames, messages) require using WS context
metadata for a WS data chunk to use it properly, and calling
'curl_ws_metadata(curl_handle, ...)' in every CURLOPT_WRITEFUNCTION
callback seems as a too high price.
No matter how fast is libcurl searching mechanism used to find WS "context
data" by a curl handle, it can't compare to the instant time which a
pointer to WS "context data" passed in the "write callback" provides.
And if we look at typical WS frameworks, they provide WS metadata as part
of their WS events and callbacks.
I think if we separate CURLOPT_WRITEFUNCTION callback (Raw data) from
CURLOPT_WS_WRITEFUNCTION callback (WS data) it will not really make things
obscure, especially for folks familiar with WebSockets.
The CURLOPT_WRITEFUNCTION will carry the same meaning - opaque HTTP data
and CURLOPT_WS_WRITEFUNCTION callback will carry WS payloads with WS
metadata available (frame or message depending on the context).
And we can extend CURLOPT_WS_WRITEFUNCTION to an even more generic callback
- "high_level_protocol_write_function " - a callback which can be used to
pass high-level protocol data running on top of HTTP (or some other
transport protocol).
This callback can have parameters: protocol (WS in our case), data, size,
protocol_context, userdata (maybe some more), and can be used as a general
mechanism for protocols like WS.
With this approach, the CURLOPT_WRITEFUNCTION will be always kept as a
callback for the "primary" transport protocol (like HTTP for WS) - and
provide raw data carried over that protocol.
Date: Tue, 21 Jun 2022 19:02:21 +0200
Message: 1
Date: Mon, 20 Jun 2022 21:58:59 +0000
From: Dmitry Karpov <dkarpov_at_roku.com>
To: Dmitry Karpov via curl-library <curl-library_at_lists.haxx.se>
Subject: RE: About a websockets write callback
Message-ID:
<
DM6PR01MB5611D2DB80A2A39FF84AEFA8C3B09_at_DM6PR01MB5611.prod.exchangelabs.com>
Content-Type: text/plain; charset="us-ascii"
Yes, it would be nice to have just one callback for all WS modes (RAW,
FRAME, MESSAGE) but using CURLOPT_WRITEFUNCTION callback for that purpose
doesn't seem like an optimal solution to me because of the problems related
to passing curl handle to it and making a function call to get WS context
metadata.
All WS levels above RAW (frames, messages) require using WS context
metadata for a WS data chunk to use it properly, and calling
'curl_ws_metadata(curl_handle, ...)' in every CURLOPT_WRITEFUNCTION
callback seems as a too high price.
No matter how fast is libcurl searching mechanism used to find WS "context
data" by a curl handle, it can't compare to the instant time which a
pointer to WS "context data" passed in the "write callback" provides.
And if we look at typical WS frameworks, they provide WS metadata as part
of their WS events and callbacks.
I think if we separate CURLOPT_WRITEFUNCTION callback (Raw data) from
CURLOPT_WS_WRITEFUNCTION callback (WS data) it will not really make things
obscure, especially for folks familiar with WebSockets.
The CURLOPT_WRITEFUNCTION will carry the same meaning - opaque HTTP data
and CURLOPT_WS_WRITEFUNCTION callback will carry WS payloads with WS
metadata available (frame or message depending on the context).
And we can extend CURLOPT_WS_WRITEFUNCTION to an even more generic callback
- "high_level_protocol_write_function " - a callback which can be used to
pass high-level protocol data running on top of HTTP (or some other
transport protocol).
This callback can have parameters: protocol (WS in our case), data, size,
protocol_context, userdata (maybe some more), and can be used as a general
mechanism for protocols like WS.
With this approach, the CURLOPT_WRITEFUNCTION will be always kept as a
callback for the "primary" transport protocol (like HTTP for WS) - and
provide raw data carried over that protocol.
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2022-06-21