The implementation of zstd compression/decompression is fairly simple as the underlying zstd-jni library provides a JVM stream implementation with ByteBuffer's that does most of the hard work.
I should be done this week, at the point of writing tests now. I understand wanting to unblock satellite modules but at the same time I cannot implement zstd request/response compression without this change and having to wait an entire month or so for another milestone is unnecessary (in my view) On Mon, Oct 27, 2025 at 10:07 AM Arnout Engelen <[email protected]> wrote: > I'm not sure we should further delay the milestone for this, but since > we're still waiting for https://issues.apache.org/jira/browse/INFRA-27312 > there > might be a good chance of getting it in anyway ;) > > On Mon, Oct 27, 2025 at 8:38 AM Matthew de Detrich <[email protected]> > wrote: > > > Sorry to add one thing onto the list, but I am currently working on > > https://github.com/apache/pekko/issues/2404 and it would make sense for > > this to be done and tested for the 2.0.0-M1 release so that pekko-http > can > > use the zstd compression/decompression flow for http responses/requests > > that are compressed via zstd (its now an rfc standard in the same way > gzip > > is and browsers have added support for it, see > > https://en.wikipedia.org/wiki/Zstd). > > > > On Fri, Oct 10, 2025 at 5:12 PM Arnout Engelen <[email protected]> > wrote: > > > > > Jup. I'd like to stage it via > https://github.com/apache/pekko/pull/2314 > > - > > > reviews welcome :) > > > > > > On Thu, Oct 9, 2025 at 10:48 PM Matthew de Detrich < > [email protected] > > > > > > wrote: > > > > > > > Now is indeed a good time for a M1, there are more changes that we > can > > do > > > > that I think would be useful but most importantly we should unblock > > > > satellite projects > > > > > > > > On Wed 1. Oct 2025 at 11:44, PJ Fanning <[email protected]> > wrote: > > > > > > > > > Now that we have the Scala 2.13.17 uptake done, I think we are in a > > > good > > > > > position to do a code freeze on the main branch and proceed with an > > > RC. I > > > > > guess the timing will depend on Arnout's availability. > > > > > > > > > > > > > > > On 2025/09/29 09:48:28 kerr wrote: > > > > > > +1, any update can come up in other Milestones > > > > > > 何品 > > > > > > > > > > > > > > > > > > Arnout Engelen <[email protected]> 于2025年9月29日周一 16:48写道： > > > > > > > > > > > > > +1, and I volunteer to RM > > > > > > > > > > > > > > On Sun, Sep 28, 2025 at 2:01 PM PJ Fanning < > [email protected] > > > > > > > > wrote: > > > > > > > > > > > > > > > There are quite a few changes completed for the milestone > > > already. > > > > > > > > https://github.com/apache/pekko/milestone/5?closed=1 > > > > > > > > > > > > > > > > I propose that we aim to finish up some of the changes that > are > > > > ready > > > > > > > > to go and create an RC and start a vote in maybe a week's > time. > > > > > > > > > > > > > > > > I would expect at least 1 more milestone with significant > > changes > > > > > > > > before we try to stabilise the branch for a final 2.0.0 > > release. > > > > > > > > > > > > > > > > I think it is best to maybe park discussion on the 1 or 2 > more > > > > > debated > > > > > > > > changes and come back to them in a few weeks. > > > > > > > > > > > > > > > > The advantage of getting an M1 out there is that we can > create > > > > > > > > equivalent M1s for Pekko HTTP, gRPC, Connectors, etc and > > > facilitate > > > > > > > > lib maintainers and others who might like to see how easy or > > > > > otherwise > > > > > > > > it is for them to support the 2.0.0 changes. > > > > > > > > > > > > > > > > The 2.0.0 jars are not expected to work well with libs that > > were > > > > > > > > compiled with Pekko 1.x dependencies. I think most use cases > > will > > > > > just > > > > > > > > require some small code changes and recompilation. It could > be > > a > > > > > > > > number of weeks before downstream Pekko libs (HTTP, gRPC, > > > > Connectors, > > > > > > > > etc) are ready for this. > > > > > > > > > > > > > > > > Pekko 1.x will continue to be maintained. > > > > > > > > > > > > > > > > What do people think? > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > To unsubscribe, e-mail: [email protected] > > > > > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > Arnout Engelen > > > > > > > ASF Security Response > > > > > > > Apache Pekko PMC member, ASF Member > > > > > > > NixOS Committer > > > > > > > Independent Open Source consultant > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: [email protected] > > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > > > > > > > > > > > -- > > > Arnout Engelen > > > ASF Security Response > > > Apache Pekko PMC member, ASF Member > > > NixOS Committer > > > Independent Open Source consultant > > > > > > > > -- > Arnout Engelen > ASF Security Response > Apache Pekko PMC member, ASF Member > NixOS Committer > Independent Open Source consultant >
