On 1. 6. 25 23:00, Daniel Sahlberg wrote:
Den sön 1 juni 2025 kl 13:58 skrev Branko Čibej <br...@apache.org>:
On 1. 6. 25 13:20, Timofei Zhakov wrote:
> On Sun, Jun 1, 2025 at 12:56 PM Branko Čibej <br...@apache.org>
wrote:
> Anyway, yes, that should be backported from trunk, even
though it has
> already been superseded. As should all the other CMake build
changes
> that are on trunk but not in 1.4.x.
>
> I'll try to update 1.4.x/STATUS with all the myriad changes
now in
> flight, but I suspect that at some point, we'll just decide to
> bulk-merge from trunk to that branch.
>
>
> It would be very useful to get cmake released in serf (and svn
btw!)
> and quit experimental status. I'm free to help in place of cmake.
Cool! CMake on trunk is "done", in the sense that it has feature
parity
with the SCons build. But it needs a lot of testing and review --
see my
other mail, subject "CMake build status" from 30 May. I've tested
it on
Windows, but it would be nice to have more eyes on that. It would be
even nicer to test a Subversion build with serf-trunk, I didn't get
around to that yet.
And backport to 1.4.x, of course.
And finally a release from 1.4.x ... it's time.
-- Brane
Would it make sense to completely replace the current 1.4.x with
/trunk, or even declare 1.4.x "not released" and prepare a 1.5.x
branch instead?
*shrug* Version numbers are cheap.
Could someone summarize, or help me how to figure out, the major
differences between 1.3.x and trunk? I think I've seen something about
HTTPv2 support, but I don't know how complete it is. Would there be
any major issues for our users?
Quite a lot of changes there. Let's see, off the top of my head -- most
of these are also on the 1.4.x branch:
* Support for Brotli decoding (but not encoding).
* HTTP/2, and you'd have to ask the authors how complete it is.
* Support for OCSP verification (1.3.x has only OCSP stapling, IIRC,
trunk/1.4.x has the full OCSP request/response workflow)
* Python ctypes bindings, which have probably already bitroted; I
don't know if anyone is using them.
* The CMake build
* The new protocols and connections API, which Bert was working on,
but it's disabled by default (#if 0) -- that's meant for acutal
serf-2.0, I think, not for 1.x.
* I've started working on a simple mechanism to allow users to
register new authentication scheme implementations at runtime. This
grew from the discussion with Peter Balogh about 2FA; turns out that
authentication schemes are currently hard-coded in the library, to
add a new one you have to implement it in Serf, users can't just
register their own handlers.
Plus bug fixes and so on.
Also it appears that the SCons build doesn't work with SCons 4.x earlier
than 4.7, now I'll have to set up Debian-stable VM to debug that. :(
-- Brane
