I would prefer adding in netty 4 support for the classic transport mechanism because it gives people an upgrade path while allowing them to resolve the CVE issues. If Pekko 1.1.x didn't support the classic transport mechanism then it forces Pekko users to be stuck on 1.0.x with no easy upgrade path.
If its possible to upgrade the classic remoting mechanism to Netty 4 that would be ideal, of course we can then mark the classic transport mechanism as deprecated in 1.1.x and then remove it in 1.2.x In general I think this is the general attitude we should have with these matters, it's fine to deprecate/remove things but an upgrade path needs to be provided, especially if we deal with CVE's which is a forcing hand. On Mon, Jul 31, 2023 at 9:07 PM kerr <hepin1...@gmail.com> wrote: > The classic transport lack the dedicated channel for bigger messages and > internal system messages , and depends on netty v3 which have CVEs. > But there are projects depend on it and use the old transport. do you think > instead of the remove it, but update it to netty 4 will help? > > I implemented a netty 4 based transport once when I was work for a game > company, will not be much hard to migrate to netty 4. > > 何品 > -- Matthew de Detrich *Aiven Deutschland GmbH* Immanuelkirchstraße 26, 10405 Berlin Amtsgericht Charlottenburg, HRB 209739 B Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen *m:* +491603708037 *w:* aiven.io *e:* matthew.dedetr...@aiven.io
