Re: Refactoring the HTTP/2 API

2021-03-11 Thread Mark Thomas
On 11/03/2021 10:53, Romain Manni-Bucau wrote: +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. Possible yes, but I am concerned about the vo

Re: Refactoring the HTTP/2 API

2021-03-11 Thread Martin Grigorov
On Thu, Mar 11, 2021 at 12:03 PM Mark Thomas 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 re

Re: Refactoring the HTTP/2 API

2021-03-11 Thread Romain Manni-Bucau
+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 | Blog

Re: Refactoring the HTTP/2 API

2021-03-11 Thread Rémy Maucherat
On Thu, Mar 11, 2021 at 11:03 AM Mark Thomas 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 re

Refactoring the HTTP/2 API

2021-03-11 Thread Mark Thomas
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 b