Buy commercial curl support. 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 Daniel himself.
Re: Libcurl and WebSockets
- 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: Wed, 8 Jan 2025 13:43:15 +0100 (CET)
On Tue, 7 Jan 2025, Gavin D. Howard via curl-library wrote:
> However, I think the "client side only" part of libcurl is already dead,
> and I think that you were the one to kill it.
>
> The reason I think so is your own advice to not mix URL parsers I
> previously mentioned. [2]
Okay, that is one way to look at it but I think it is a stretch.
Several of the API calls in the library can certainly be used even when you
implement server-side components, but I don't think that significantly changes
the "client side only" rule. It is just that some functions are general
purpose enough to get used even outside pure client side roles.
> Again, I am biased (although I am willing to help out!), but I think the
> world would be incredibly blessed to have a libcurl that can be on both ends
> of the network because servers are often clients themselves, and using one
> library for both would reduce code duplication and attack surface.
Yes, for users already using libcurl anyway, putting adjacent functionality
into libcurl makes perfect sense. It does not necessarily mean it is a good
idea for the library in general. We get suggestions for adding feature XYZ all
the time when users are already using XYZ + libcurl.
> And if I were to appeal to your need for food and shelter, I think there
> would be more companies willing to pay for professional support on libcurl
I appreciate your concern for my livelihood, I really do. curl is however not
done for *me* nor *my* concerns. It is a team effort with a huge community and
a giant user base. For the world.
My opinions about what curl should and should not do is not based on possible
revenue or income. It is rather for functionality, stability, sustainability
etc. Including avoiding creeping featurism - especially features that is or
could be seen as outside of curl's scope.
> I think WebSockets would be a great pilot program for that since it's so
> symmetrical, and I would bet there are already servers running it with the
> raw API.
Exactly how would this new proposed look and work? I can't even fathom how an
API for this would look like to be usable in a server setting.
Date: Wed, 8 Jan 2025 13:43:15 +0100 (CET)
On Tue, 7 Jan 2025, Gavin D. Howard via curl-library wrote:
> However, I think the "client side only" part of libcurl is already dead,
> and I think that you were the one to kill it.
>
> The reason I think so is your own advice to not mix URL parsers I
> previously mentioned. [2]
Okay, that is one way to look at it but I think it is a stretch.
Several of the API calls in the library can certainly be used even when you
implement server-side components, but I don't think that significantly changes
the "client side only" rule. It is just that some functions are general
purpose enough to get used even outside pure client side roles.
> Again, I am biased (although I am willing to help out!), but I think the
> world would be incredibly blessed to have a libcurl that can be on both ends
> of the network because servers are often clients themselves, and using one
> library for both would reduce code duplication and attack surface.
Yes, for users already using libcurl anyway, putting adjacent functionality
into libcurl makes perfect sense. It does not necessarily mean it is a good
idea for the library in general. We get suggestions for adding feature XYZ all
the time when users are already using XYZ + libcurl.
> And if I were to appeal to your need for food and shelter, I think there
> would be more companies willing to pay for professional support on libcurl
I appreciate your concern for my livelihood, I really do. curl is however not
done for *me* nor *my* concerns. It is a team effort with a huge community and
a giant user base. For the world.
My opinions about what curl should and should not do is not based on possible
revenue or income. It is rather for functionality, stability, sustainability
etc. Including avoiding creeping featurism - especially features that is or
could be seen as outside of curl's scope.
> I think WebSockets would be a great pilot program for that since it's so
> symmetrical, and I would bet there are already servers running it with the
> raw API.
Exactly how would this new proposed look and work? I can't even fathom how an
API for this would look like to be usable in a server setting.
-- / daniel.haxx.se || https://rock-solid.curl.dev -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2025-01-08