Re: Refactoring the HTTP/2 API

[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 volume of additional code 
this might require.


My current plan is to align the current 8.5.x code with 9.0.x/10.0.x 
which means:

- lots of reduced visibility
- some increased visibility
- removing deprecated code

and then leave it for a few releases to see if there are any issues 
before embarking on the more extensive refactoring / renaming. This will 
make it easier to revert any aspects of the changes that are causing 
issues before I start on the wider refactoring.


There are some new features in 9.0.x/10.0.x that aren't supported in 
8.5.x. I'll need to decide what to do with those. There are also the 
impacts of a few wider refactorings in 9.0.x/10.0.x that I need to 
figure out how to deal with.


With all of the above, the overall aim is to make the HTTP/2 code more 
aligned across versions and easier to maintain.


Mark






Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le jeu. 11 mars 2021 à 11:45, Rémy Maucherat  a écrit :


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 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









-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Refactoring the HTTP/2 API

[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 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?
>

No objections from me!

Martin


>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: Refactoring the HTTP/2 API

[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
 | Old Blog
 | Github  |
LinkedIn  | Book



Le jeu. 11 mars 2021 à 11:45, Rémy Maucherat  a écrit :

> 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 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
> >
> >
>

Re: Refactoring the HTTP/2 API

[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 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
>
>

Refactoring the HTTP/2 API

[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 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?

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org