Preliminary draft PR is already open for discussion, see https://github.com/apache/pekko/pull/2409
On Mon, Oct 27, 2025 at 10:20 AM Matthew de Detrich <[email protected]> wrote: > 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 >> >
