Servlet API serves as the server-side programming interfaces for HTTP. In
light of the HTTP/2 development, I'd suggest the following:
1. Evaluate any gaps with the latest httpbis specs, that are visible to
applications
2. Evaluate HTTP/2 introduced features (if any), that are visible to
applications
3. Minimize any exposure of HTTP/2 wire-level detail, which will likely
evolve (now that the door is open). Note SPDY is largely transparent to
server-APIs (and client-APIs).
4. Evaluate opportunities for improved end-to-end API semantics, e.g.
parallel request/response streaming, JSON (or any MIME encoding) support,
flow-control, session, oauth ...
Comments on the proposal:
1. I don't believe Servlet 4.0 should or will benefit the WebSocket API,
directly or indirectly, even if HTTP/2 is deemed as a better wire-protocol
for WebSocket.
2. It's not clear to me why the SPDY latency improvement has anything to do
with the Servlet API. E.g. we probably don't need a new API when TCP/TLS is
improved
Look forward to the new spec effort.
- Wenbo Zhu (Google)
On Tue, Jul 22, 2014 at 4:02 PM, Shing Wai Chan <shing.wai.chan_at_oracle.com>
wrote:
> Hello Servlet User Community,
>
> After accomplishing Servlet 3.1 in Java EE 7, with emerging of HTTP 2,
> it's time to start working on Servlet 4.0.
> I have enclosed a proposal for the JSR text that is open to change before
> we file with JCP.
>
> We are going to use the same open and transparent process to develop
> Servlet 4.0 as we have before.
>
> Finally, I am happy to announce that Edward Burns will be my co-spec lead.
>
> Both Ed and I are looking forward to working with you all on Servlet 4.0.
>
> Sincerely,
>
> Shing Wai Chan
> Servlet Spec co-lead
>