On 2. 7. 25 18:42, Graham Leggett wrote:
On 02 Jul 2025, at 17:16, Ivan Zhakov<i...@apache.org> wrote:
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'm not so sure - at the end of all this effort, all you end up with is the
same code in a different place. I'm not seeing that as a huge benefit.
I think the fact that serf exists and can be used by people independently of
subversion is far more valuable in the long term. I wish more people would use
async libraries.
I know for a fact that Serf is used elsewhere, in proprietary contexts
that no research of public sources will tell you about. Precisely
because it's asynchronous.
2. Some popular package managers like Homebrew don't even offer libserf as
a separate package, also indicating its lack of independent adoption.
Homebrew is not a "some popuar package managers", it's in fact the only
one I know about that doesn't provide a standalone libserf. MacPorts
does, as do all Linuxes and "the" three *BSDs. Even Haiku has serf
packaged separately.
And even if this were true, I agree with Graham.
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.
So why doesn't Subversion have a libsvn_ra_curl?
"While I appreciate Subversions's internal design and
implementation, I think there are no compelling reasons to choose it
for a new project over alternatives like git."
By your argument, Subversion should just go to the Attic since most
people these days use git. Wasting time on new features, let alone new
releases, is not economical.
4. Subversion is already developing new features that rely on unreleased
Serf APIs and capabilities.
Well, that's just misleading. Graham is right at this time preparing
patches for Subversion to use (a) feature(s) that he is, at the same
time, adding to Serf. Generalising from a single data point is not a
valid argument.
5. Almost all Serf committers are also Subversion committers.
This is not an accident, it's intentional.
This means that the actual development community is shared, rather than
diverse.
Yes, and? Why is that a bad thing, for Serf specifically?
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.
Subversion's and Serfs internal architectures are completely different.
Subversion is streamy, Serf is asynchronous. It's not all that obvious
that there'd be much overlap. Using svn_error_t within Serf isn't such a
boon as you might think, as it's not designed for the kind of error
reporting that Serf needs (arguably "should have but doesn't").
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 for one see some fallacies in your logic.
You'll have to explain in far more detail why you think that merging the
two projects would "simplify new feature development". Because you'd
have to prepare a single patch instead of two? That wouldn't go away.
The idea of focusing on "features and less on API and build
dependencies" is a bit strange, too. I see that as more of a bad than a
good thing. And which "build dependencies" are we focusing on to the
detriment of everything else?
-- Brane
