2015-05-29 11:13 GMT+02:00 Mark Thomas <ma...@apache.org>: > On 15/05/2015 19:46, Rémy Maucherat wrote: > > 2015-05-13 22:57 GMT+02:00 Mark Thomas <ma...@apache.org>: > > <snip/> > > >> The next steps are to get a basic implementation working which means: > >> - figure out how to feed requests into Tomcat's processing chain > >> - figure out how to extract the response back into the HTTP/2 > >> implementation. > > > > Is it really a good idea to use the same API for HTTP/2 servlets ? I > > haven't seen anything going on in the expert group. > > The little discussion there has been has been around using a > RequestDispatcher to trigger server push. There is a strong implication > there that the existing API will be extended rather than a new one > added. Based on the general Java EE views on backwards compatibility I'm > expecting HTTP/2 to have to work (at some level) with existing Servlets. > What the extended API will look like for HTTP/2 is TBD at this point. >
Ok, well, as far as I am concerned that's a mistake, it should have an async IO API on top to make the most out of it. I'll follow the discussions obviously. I'm not very convinced about server push either ... One of the features that could be not so useful in practice. > > I have now plumbed in basic request/response processing. > > Kudos to those behind the Tomcat 4.1.x refactoring. It was a long time > ago (before my time on the project) but the API put in place then made > it incredibly easy to plumb the HTTP/2 stuff into the existing code. > Thanks, at least it still works well enough :) > > There are still plenty of TODOs (flow control is ignored for request > bodies for example) but you should be able to navigate around the > examples app. Note: the async examples don't work (as expected - I > haven't looked at that yet). > > The next steps are: > - implement the state machine for streams; > - start thinking about how/when to clean up closed streams; > - address the various TODOs throughout the code (ignored frame types, > error conditions, etc); > - implement the various restrictions required by the spec that > we currently ignore and just hope the client does the right thing. > - add async / non-blocking I/O support > > Ok ! Rémy
