+1, just wonder if in 8.5 both cant stay somehow (like just adding) by delegating the new method to the "old" ones? Would mitigate the breaking changes and enable the API to stay most likely compatible.
Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le jeu. 11 mars 2021 à 11:45, Rémy Maucherat <r...@apache.org> a écrit : > On Thu, Mar 11, 2021 at 11:03 AM Mark Thomas <ma...@apache.org> wrote: > > > Hi all, > > > > I've been spending a lot of time looking at the HTTP/2 code lately. It > > has become apparent to me that the naming of various methods is not as > > clear as it code be. For example, it is not clear if a method is: > > - triggered by receiving a given frame > > - will send a given frame > > - is called before/after receiving/sending a given frame to update state > > - somethign else > > I'd like to fix this. Mostly, this means renaming a lot of the methods. > > > > In 10.0.x and 9.0.x much of the API is package private so we are > > relatively free to make changes. That is not the case with 8.5.x. > > However, I'd *really* like to keep the HTTP/2 code aligned between all > > versions as much as possible. > > > > We have made changes to the 8.5.x public API in the past (adding > > methods, adding parameters to methods) and we haven't received any > > negative feedback afterwards. Also, the HTTP/2 code is unlikely to be > > extended for some custom purpose. > > > > Given all of the above, I'd like to bring the current HTTP/2 code into > > alignment across all three versions. The majority of the changes will be > > in the public API in 8.5.x. > > > > Are there any objections to me doing this? > > > > You can try it, but I suppose if anyone complains you'll have to take it > out. > > Rémy > > > > > Mark > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: dev-h...@tomcat.apache.org > > > > >
