On Fri, 27 Jun 2025 at 11:43, Daniel Sahlberg <daniel.l.sahlb...@gmail.com> wrote:
> Hi, > > I'm very happy to see the rekindled interest in Serf development and the > recent work by Brane on the user-defined-authn branch and by Graham on the > OpenSSL "certificate by URI" PR. I'm planning on reviewing those things > during the weekend. When these are merged (and it doesn't only depend on > me, it is of course a team effort reviewing and merging!) we should start > thinking about a new release. > > I don't think it makes sense to backport to 1.3 - they would add new APIs > that require a version bump. > > The existing 1.4.x branch was created in 2018 and received a few backports > the same year but it lacks significant work from trunk, for example > Evgeny's OpenSSL3 work in 2022 that led up to the release of 1.3.10. > > I'm proposing to drop the current 1.4.x branch and create a new one based > on trunk. Alternative option to drop 1.4.x completely and instead name the > new release 1.5. > > As far as I understand trunk contains a bunch of HTTP 2-work, but according > to Brane earlier on dev@ some is hidden behind #ifdefs that will only > expose it if released as Serf 2. Would it make sense to get this released > as well? In that case, should we instead aim for Serf 2.0? Alternative > option to remove the #ifdefs and declare it stable in Serf 1. I'd like to share an alternative perspective (my two cents) on this topic. In short, I believe there are strong, practical reasons to merge Serf directly into Subversion: 1. Based on publicly available information, Subversion is the only actual user of Serf. I checked major Linux distributions (Ubuntu, Debian, CentOS, OpenSUSE) and Subversion is consistently the only dependency listed for libserf: - Ubuntu: https://ubuntu.pkgs.org/25.04/ubuntu-universe-amd64/libserf-1-1_1.3.10-3ubuntu1_amd64.deb.html - Debian: https://debian.pkgs.org/12/debian-main-amd64/libserf-1-1_1.3.9-11_amd64.deb.html - CentOS: https://centos.pkgs.org/10-stream/centos-appstream-x86_64/libserf-1.3.10-7.el10.x86_64.rpm.html - OpenSUSE: https://opensuse.pkgs.org/15.6/opensuse-oss/libserf-1-1-1.3.9-150600.16.2.x86_64.rpm.html 2. Some popular package managers like Homebrew don't even offer libserf as a separate package, also indicating its lack of independent adoption. 3. While I appreciate Serf's internal design and implementation, I think there are no compelling reasons to choose it for a new project over alternatives like libcurl. For example, libcurl offers comprehensive support for: - Authentication types (SSPI, CRAM, SASL, OAuth2, Kerberos, etc.) - TLS implementations (OpenSSL, Schannel, BearSSL, GnuTLS, Mbed TLS, Rustls, wolfSSL) - Modern protocols (HTTP/2, HTTP/3) Serf's primary advantage, which I believe is in how it handles asynchronous multiplexing, doesn't appear to be a widely demanded feature for most users. 4. Subversion is already developing new features that rely on unreleased Serf APIs and capabilities. This demonstrates a deep interdependency between the two projects. 5. Almost all Serf committers are also Subversion committers. This means that the actual development community is shared, rather than diverse. 6. Merging Serf into Subversion would eliminate the need to reinvent various patterns in Serf, such as svn_error_t. This could allow reusing existing common primitives within Subversion. With these points in mind, merging Serf into Subversion could be a logical step. It would simplify new feature development, allowing more focus on features and less on API and build dependencies. -- Ivan Zhakov
