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: About a websockets write callback
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Daniel Stenberg via curl-library <curl-library_at_lists.haxx.se>
Date: Sat, 18 Jun 2022 13:08:05 +0200 (CEST)
On Fri, 17 Jun 2022, Dmitry Karpov via curl-library wrote:
> 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.
Oh yes that's a neat idea! I like this.
> 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.
I think I prefer to re-use the same callback, in particular if you think of
applications that would use a mix of websocket and other protocols to download
data. But in the frame-parse mode there needs to be a way for the application
to figure out the parsed details of the frame.
> 3. WS_MSG_WRITEFUNC callback - provides assembled WS message information -
> message data and metadata.
I think I prefer to have an option for "ws mode" that would be RAW, FRAME or
MESSAGE and have the same callback used for all of them. But the 'MESSAGE'
mode might be something I save for a later PR once RAW and FRAME have landed
work.
Having the same callback also removes the problems of having mulitple mutually
exclusive options and protocol-specific behaviors for options == easier to
document and for users to understand the data flow.
Date: Sat, 18 Jun 2022 13:08:05 +0200 (CEST)
On Fri, 17 Jun 2022, Dmitry Karpov via curl-library wrote:
> 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.
Oh yes that's a neat idea! I like this.
> 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.
I think I prefer to re-use the same callback, in particular if you think of
applications that would use a mix of websocket and other protocols to download
data. But in the frame-parse mode there needs to be a way for the application
to figure out the parsed details of the frame.
> 3. WS_MSG_WRITEFUNC callback - provides assembled WS message information -
> message data and metadata.
I think I prefer to have an option for "ws mode" that would be RAW, FRAME or
MESSAGE and have the same callback used for all of them. But the 'MESSAGE'
mode might be something I save for a later PR once RAW and FRAME have landed
work.
Having the same callback also removes the problems of having mulitple mutually
exclusive options and protocol-specific behaviors for options == easier to
document and for users to understand the data flow.
-- / 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.htmlReceived on 2022-06-18