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: Weston Schmidt via curl-library <curl-library_at_lists.haxx.se>
Date: Fri, 17 Jun 2022 06:12:21 -0700
I tend to agree that the existing function signature is a bit too restrictive.
If you don't want a unique to WS function, how about adding a different
variant across the board for folks?
What about adding a CURLOPT_CTX_WRITEFUNCTION where a
context object is passed that allows for access back to the curl object &
access to metadata that might be specific to that function call, etc.
If you want, you could replace the void *userdata with the ctx & then users
could make a curl_ctx_get_userdata(ctx) vs add more arguments.
For a WS, maybe only CURLOPT_CTX_WRITEFUNCTION is supported,
but maybe this is an alternative callback to the existing write() format one?
Wes
On Fri, Jun 17, 2022 at 5:59 AM Nicolas Mora via curl-library
<curl-library_at_lists.haxx.se> wrote:
>
> Hello,
>
> Here are my 2 öre based on my implementation of a websocket library.
>
> Le 2022-06-17 à 07 h 39, Daniel Stenberg via curl-library a écrit :
> >
> > I would like to provide websockets data with the CURLOPT_WRITEFUNCTION
> > callback as well. But how would libcurl provide the additional necessary
> > metadata?
> >
> I assume when you talk about the CURLOPT_WRITEFUNCTION, it's related to
> an incoming websocket message from the server to libcurl.
>
> based on the write_callback definition, it's difficult to provide the
> metadata in it.
> For example, one could say that "for a websocket incoming message, the
> first write_callback call, the *ptr value will contain the message
> datestamp, the second call will contain the opcode, etc." Which would be
> hard for users to work with, at least.
>
> > 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()'.
> >
> My best guess is to use a new curl option, something like
> CURLOPT_WS_WRITEFUNCTION with a specific write_callback callback.
>
> In this callback function libcurl would pass a pointer to a structure
> that will contain the message metadata. Those metadata would be
> accessible via the curl_ws_metadata() for example.
>
> Another advantage of a specific websocket callback function would be
> that this function will allow to manage the websocket entire communication.
>
> For example, a received message can be ignored by the app, or the app
> can disconnect the websocket if required, or send a message in answer to
> a received one, etc.
>
> /Nicolas
> --
> Unsubscribe: https://lists.haxx.se/listinfo/curl-library
> Etiquette: https://curl.se/mail/etiquette.html
Date: Fri, 17 Jun 2022 06:12:21 -0700
I tend to agree that the existing function signature is a bit too restrictive.
If you don't want a unique to WS function, how about adding a different
variant across the board for folks?
What about adding a CURLOPT_CTX_WRITEFUNCTION where a
context object is passed that allows for access back to the curl object &
access to metadata that might be specific to that function call, etc.
If you want, you could replace the void *userdata with the ctx & then users
could make a curl_ctx_get_userdata(ctx) vs add more arguments.
For a WS, maybe only CURLOPT_CTX_WRITEFUNCTION is supported,
but maybe this is an alternative callback to the existing write() format one?
Wes
On Fri, Jun 17, 2022 at 5:59 AM Nicolas Mora via curl-library
<curl-library_at_lists.haxx.se> wrote:
>
> Hello,
>
> Here are my 2 öre based on my implementation of a websocket library.
>
> Le 2022-06-17 à 07 h 39, Daniel Stenberg via curl-library a écrit :
> >
> > I would like to provide websockets data with the CURLOPT_WRITEFUNCTION
> > callback as well. But how would libcurl provide the additional necessary
> > metadata?
> >
> I assume when you talk about the CURLOPT_WRITEFUNCTION, it's related to
> an incoming websocket message from the server to libcurl.
>
> based on the write_callback definition, it's difficult to provide the
> metadata in it.
> For example, one could say that "for a websocket incoming message, the
> first write_callback call, the *ptr value will contain the message
> datestamp, the second call will contain the opcode, etc." Which would be
> hard for users to work with, at least.
>
> > 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()'.
> >
> My best guess is to use a new curl option, something like
> CURLOPT_WS_WRITEFUNCTION with a specific write_callback callback.
>
> In this callback function libcurl would pass a pointer to a structure
> that will contain the message metadata. Those metadata would be
> accessible via the curl_ws_metadata() for example.
>
> Another advantage of a specific websocket callback function would be
> that this function will allow to manage the websocket entire communication.
>
> For example, a received message can be ignored by the app, or the app
> can disconnect the websocket if required, or send a message in answer to
> a received one, etc.
>
> /Nicolas
> --
> 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.htmlReceived on 2022-06-17