Hello,
I think that the approach using separate WS callbacks is better.
For WS transfers, the CURLOPT_WRITEFUNCTION callback always must be used with
"message metadata" calls, otherwise it is useless.
So, besides the need to somehow pass a curl handle inside the write callback to
get metadata for a WS message, there is also performance price for additional
'curl_ws_metadata()' function calls inside every WS CURLOPT_WRITEFUNCTION
callback call.
Dedicated WS callbacks can provide WS message metadata without all these
drawbacks.
As someone, who already implemented WS protocol using libcurl, ideally I would
like to have the following set of callbacks for WS transfers:
1. CURLOPT_WRITEFUNCTION callback - provides raw WS data after initial WS
negotiation over HTTP is done.
- This would allow to plugin easily existing custom WS implementations
that use their own frame parsing and message assembling.
2. WS_FRAME_WRITEFUNC callback - provides parsed WS frame information - header
and frame data.
- This would allow to provide custom WS extensions, like multiplexing
etc.
3. WS_MSG_WRITEFUNC callback - provides assembled WS message information -
message data and metadata.
- This would allow to work with basic and mostly used WS messages (text,
binary, ping etc).
Thanks,
Dmitry Karpov
-----Original Message-----
From: curl-library <curl-library-boun...@lists.haxx.se> On Behalf Of Daniel
Stenberg via curl-library
Sent: Friday, June 17, 2022 4:39 AM
To: libcurl hacking <curl-library@lists.haxx.se>
Cc: Daniel Stenberg <dan...@haxx.se>
Subject: About a websockets write callback
Hello,
Last year when we brainstormed different takes on a WebSockets idea, we landed
on a separate ws callback for writing data, similar to the regular
CURLOPT_WRITEFUNCTION. [*]
A separate callback, because it needs to provide some additional data that the
plain callback doesn't receive.
Now when I've started working on implementing websockets, I'm having second
thoughts on that design but I can't decide on what's a better way. So I'm here
to see if someone else can fix this for me! =)
I would like to provide websockets data with the CURLOPT_WRITEFUNCTION callback
as well. But how would libcurl provide the additional necessary metadata?
My initial thought was to provide a special websocket function that only can be
used from within the callback that would provide the extra information (type of
data, opcode, and if the FIN bit is set or not etc). Like maybe
'curl_ws_metadata()'.
This is what makes me hesitate on this idea:
This new function would need to get the easy handle as an argument, so that it
can find and return the correct information, but the CURLOPT_WRITEFUNCTION does
not pass in the easy handle! So in order to use this function within the
callback, it would require that the callback on its own design gets the easy
handle passed into it via the CURLOPT_WRITEDATA option in some manner.
Would that be a sensible requirement or would be asking too much of an
application?
Or can we come up with a better way?
[*] = https://github.com/curl/curl/wiki/WebSockets
--
/ daniel.haxx.se
| Commercial curl support up to 24x7 is available!
| Private help, bug fixes, support, ports, new features
| https://curl.se/support.html
--
Unsubscribe: https://lists.haxx.se/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
--
Unsubscribe: https://lists.haxx.se/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
