On Wed, Jul 2, 2025 at 12:17 PM Ivan Zhakov <i...@apache.org> wrote:
> 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. I made a similar suggestion some months ago (to merge the projects), which included some similar arguments. It was discussed and ultimately it seems most of the devs who responded were in favor of keeping these two projects distinct. (I'm replying from my phone so it isn't convenient to search for the relevant thread(s) in the archives but I can try later if you're interested.) Also from Subversion's perspective, a HTTP client library is a bit out of scope. That was one of the arguments made against my suggestion. Keeping Serf a separate project leaves Subversion the flexibility to swap it out for something else in the future, as was done with the switch from Neon to Serf many eons ago. So for example Subversion might consider a move to Curl as you touched on. (I might also have mentioned a move to Curl at the time, as an alternative to merging the projects, though I didn't take time to analyze how much work that would require). Anyway, back here at Serf we have added new PMC members / committers, there is renewed interest and development here, and it looks like there will be a release in the near future, after some issues are sorted out, so between these positive developments and the input received back when I suggested to merge the projects, I'm satisfied to keep the projects separate for the time being. One suggestion I would make is to try to describe Serf's advantages (such as the asynchronous aspect) a bit better on the serf.a.o website. I know it's the first bulletpoint but someone who comes across the site may not realize how significant that bulletpoint potentially is for their project. I can try to help with this, provided the other devs will be patient when I ask some potentially dumb questions. :-) Thanks for providing your thoughts. It's always good to consider alternative ideas (even if it looks like there isn't much support for this one in particular). Thanks, Nathan
