> On Jul 2, 2021, at 7:40 AM, Daniel Stenberg <dan...@haxx.se> wrote: > > On Fri, 2 Jul 2021, Felipe Gasper wrote: > > Thanks! > >> The send interface could look much like curl_easy_send(): >> >> curl_ws_send( easy, buffer, buflen, &sent, enum curl_ws_message_type type, >> enum curl_ws_flags flags ) > > Or perhaps with the type and flags just made as a single bitmask.
This will make it impossible to specify a continuation frame rather than a data frame. (Context: when a message is fragmented, the message’s first frame is text/binary, and the latter ones are continuation.) That may be OK if curl will commit to abstracting that distinction away. Also, if WS were to add a 3rd data type -- e.g., via some extension -- then it would be possible to specify CURL_WS_TEXT | CURL_WS_FANCY_NEW_EXT_TYPE, which means curl would need to detect that. Alternatively, have separate curl_ws_send_text and curl_ws_send_binary functions? > >> Most WS libraries that I’ve seen implement reception as a callback, with a >> separate control to pause reception of incoming messages. > > I won't say that's wrong, but I don't see how a callback helps with this API. > > curl_ws_recv() could just be made to not return until the entire packet can > be returned. Or with an option to return a partial one. I assume you mean something like EAGAIN rather than actually blocking? Having the caller call curl_ws_recv() directly would mean that that same caller would need to know when the socket has data to read. I don’t know if that’s always a safe assumption. Also, WS includes ping/pong, so even if the socket has data there might not be any application-level data incoming. (Ping/pong isn’t usually exposed to the application.) > An area for consideration is how to deal with the buffer (size). I mean, if > it wants to wait for a full packet to arrive I suppose it can be large and it > might not fit in the user-provided buffer, so the application would need to > call it multiple times do drain the data. Would this argue in favour of a callback, then? Curl could just allocate as it knows it needs. The caller, then, could either memcpy or assume ownership of the buffer (by, e.g., returning CURL_WS_NOFREE from the callback). Alternatively, there is precedent here with SOCK_SEQPACKET sockets, though curl has the ability to deliver what IMO would be a smoother interface. > > I took the liberty of jotting down some of these API thoughts in the wiki > page. Still incomplete and not really functional, but I figured it could help > to stir up our collective minds.. > > https://github.com/curl/curl/wiki/WebSockets#api I feel funny asking this, but is there a comment feature in this wiki system? I don’t see such, but it would seem useful. -FG ------------------------------------------------------------------- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
