Re: Recommended way of using a custom build of libcurl in a Node.js addon

From: Timothe Litt <litt_at_acm.org>
Date: Tue, 21 Mar 2023 12:25:11 -0400

HTTP/3 is experimental.  Do you want your non-technical users to rely on
an experimental implementation?

Do you have http/3 -only servers that your addon must communicate with? 
(That would be unusual.)

Unless that's the case, in the situation you describe, I'd wait for
http/3 to be in the standard, packaged builds.

Daniel probably has current statistics, but last I knew sites that
support http/3 only were rare.  And something like 75% of web browsers
support http3 - so any http3-only site is unable to communicate with 25%
of browsers.

https://w3techs.com/technologies/details/ce-http3 indicates that only
25% of websites support http3.  In fact, only about 40% support
http/2... https://w3techs.com/technologies/comparison/ce-http2,ce-http3

http/3 has some performance advantages, but for a well-designed website
with a typical load they aren't huge.  I don't think apache httpd has
support for it yet - and it still has about 1/3 of the webserver
deployments.  (Tied with nginx).

But you can certainly go ahead with your plans.  I'm just sharing one
perspective.

Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.

On 21-Mar-23 10:36, Darshan Sen wrote:
> The primary reason why I thought that the deps should be bundled with
> the addon is that the application that would be using the addon needs
> libcurl with HTTP3 support through OpenSSL. The only option I found is
> to use the first one from https://curl.se/docs/http3.html - the ngtcp2
> version which uses the quictls fork of OpenSSL. I tried but I wasn't
> able to find a way in which libcurl with HTTP3 support from quictls
> can be used on macOS, Windows and Linux without building curl from
> source and my users lack the technical skills required to build curl
> from source. That's why, I created this thread to learn about
> solutions for this problem that I'm trying to solve and find out which
> one is the most reasonable to use here.
>
> On Tue, Mar 21, 2023 at 5:18 PM Timothe Litt via curl-library
> <curl-library_at_lists.haxx.se> wrote:
>
>
> On 21-Mar-23 04:34, Darshan Sen via curl-library wrote:
>> Hi! I'd like to incorporate a custom build of libcurl (with HTTP3
>> support) into a Node.js C++ addon
>> <https://nodejs.org/api/addons.html> that is going to be shipped
>> to some systems that don't have curl or its dependencies installed.
>> From what I can tell, the possible ways in which this can be done
>> are -
>>
>> * build a fully relocatable version of libcurl and the
>> dependency libraries
>> * statically compile libcurl into my application
>>
>> I'm not sure if there are any better solutions to this. What is
>> the recommended way of doing this?
>>
> It depends.  So you'll probably get several answers.
>
> If you take either of the choices you suggest, you also take on
> the maintenance task for libcurl and the libraries it depends on. 
> That means you'll have to update your addon whenever they have an
> issue that affects your addon - including security issues.
>
> The more components you ship, the greater the work you take on. 
> And a normal build of libcurl has quite a few dependencies.  I
> only build a subset, but a quick ldd on libcurl.so lists 26.  (Of
> course, some will be installed on most any system.)  There is no
> unified schedule for their releases, so across all the libraries,
> you may see an issue every week.  But the advantage is that your
> customers have a simple install, and only one vendor (you) to deal
> with.
>
> The alternative is to simply state that libcurl (and thus its
> dependencies) is a dependency of your addon, and require that it's
> installed.  If you are distributing your addon via a package
> manager, this is pretty simple - you specify libcurl and it's
> minimum version, and the rest is handled automatically.  The
> distributions enforce a release schedule for the other libraries
> that consolidates the library updates.  The downside is you don't
> control the exact configuration of libcurl, and your addon will
> probably encounter more versions of libcurl than if you packaged
> it.  libcurl has a stable API, but if you accidentally (or
> intentionally) rely on undocumented behaviors, this could be an issue.
>
> Unless you have the resources to devote to supporting a private
> distribution of libcurl et. al. for your customers, I'd simply
> make libcurl a dependency.  It's less work for you, and consistent
> with the way most distributions work.
>
> I'd have to see a very compelling use case to invest resources in
> a private distribution.  While it may seem simpler now, the
> long-term costs tend to become large.
>
> You'll have to decide what's best for you and your customers.
>
> Timothe Litt
> ACM Distinguished Engineer
> --------------------------
> This communication may not represent the ACM or my employer's views,
> if any, on the matters discussed.
>
> --
> Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
> Etiquette: https://curl.se/mail/etiquette.html
>

-- 
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html

Received on 2023-03-21