I guess it will be of interest for the JAX-RS frameworks.
Possible push back is that in a way it is similar to Web Sockets (not
really plain HTTP) ?
Sergey
On 27/03/15 14:15, Markus KARG wrote:
> What are the current plans at the different JAX-RS implementors
> currently? Is somebody already working on this and might like to share
> his vision, or is the topic not hot enough currently?
>
> -Markus
>
> *From:*Santiago Pericas-Geertsen
> [mailto:Santiago.PericasGeertsen_at_oracle.com]
> *Sent:* Freitag, 27. März 2015 20:02
> *To:* jsr370-experts_at_jax-rs-spec.java.net
> *Subject:* Re: Support for HTTP/2 and HPACK
>
> Markus,
>
> I read your use case as the same (or very similar) to what the HTTP/2
> spec calls “server push”. Indeed, an interesting use case.
>
> We're going to have to wait and see what kind of support the Servlet
> API is adding for this (I haven’t been following their discussions yet)
> and determine whether those changes are sufficient for JAX-RS —-and also
> decide if we intent to support this feature in an non-servlet-based
> environment.
>
> — Santiago
>
> On Mar 27, 2015, at 2:43 PM, Markus KARG <markus_at_headcrashing.eu
> <mailto:markus_at_headcrashing.eu>> wrote:
>
> Santiago,
>
> no I have not spent any particular time into the effect, as I think
> it is irrelevant for JAX-RS as an international standard (in
> comparison to the implications for products implementing that
> standard): First, as soon as Servlet will support it, and as soon as
> HTTP/2 gains broad popularity, people will ask for it, and we have
> to have a prepared answer in out pockets then -- independent of
> whether this implies complexity or not. Second, I do not propose to
> finally _expose_ it in the API, I solely kicked-off discussion what
> the implications on JAX-RS _might_be_ and how JAX-RS should and / or
> could react upon this demand. For example, it possibly might be
> enough if JAX-RS SPI translates http/2 into http/1 "under the hood"
> and keept the API as it is, i. e. transform binary-textual
> representation, or split up multiple intra-request-streams into
> separate, independent requests, then there might be no implication
> on the API. What I intend is getting the discussion started; I do
> not have any particular solution in mind. Neither do I say that
> HTTP/2 is particularly well-done. But all this is irrelevant once
> that standard is used in-field.
>
> If you ask me for the use case, there is one actually I have already
> (real world example adapted from what our software product actually
> does already):
>
> Our product offers complex XML representations, like say a project
> plan. Such a project plan XML references lots of related items, like
> say the vCards of task leads, where each vCard contains the person's
> photograph. If someone opens the project plan, normally only the top
> information is shown, then clicking down the timeline more and more
> details are shown, until the client shows all the vCards of all the
> project leads. What our software did in the first release was
> iterating all the references, hence loading all the vCards' photos
> sequentially. This is really painfully slow. The second release
> loaded vCards only when shown, but then still loads the photo as a
> secondary request. This is faster, but still seqentially.
>
> An optimization would be to tell the JAX-RS client to loads the
> project, but to include the requests for the references as http/2
> low-priority background streams (this is what it was made for when
> loading complex HTML pages containg lots of photos). What I would
> expect then would be that the high-priority "main" request (the
> project plan XML) is loaded first, while all the referenced
> low-priority photos are returned asynchronously in an unspecified
> order. Hence, our application would show up the project plan rather
> immediately to the user, but the vCards and photos would pop up
> shortly after. Reactive GUIs (like JavaFX) are already prepared for
> this style of progressing result presentation), and http/2 perfectly
> fits in this style of "parallel REST".
>
> Regards
>
> -Markus
>
> *From:*Santiago Pericas-Geertsen
> [mailto:Santiago.PericasGeertsen_at_oracle.com]
> *Sent:*Freitag, 27. März 2015 14:25
> *To:*jsr370-experts_at_jax-rs-spec.java.net
> <mailto:jsr370-experts_at_jax-rs-spec.java.net>
> *Subject:*Re: Support for HTTP/2 and HPACK
>
> Hi Markus,
>
> Have you given any thought to the implications of these new
> technologies on JAX-RS? Is there really a need to “expose" HTTP/2
> concepts in the JAX-RS API? If so, what is the use case?
>
> — Santiago
>
> On Mar 26, 2015, at 5:51 PM, Markus KARG <markus_at_headcrashing.eu
> <mailto:markus_at_headcrashing.eu>> wrote:
>
> Experts,
>
> in reaction to Ed Burns interesting talk about the status of
> HTTP/2 and HPACK support in Servlet 4 yesterday at JavaLand
> conference I just filed a marker in the spec JIRA tracker as an
> umbrella for any resulting issues.
>
> Once HTTP/2 and HPACK gain attention, we have to expect
> increasing requests for support in JAX-RS. As Servlet 4 supports
> it, I think it would be a good idea to discuss how the JAX-RS
> specification should deal with HTTP/2 and HPACK.
>
> You can find the JIRA entry
> here:https://java.net/jira/browse/JAX_RS_SPEC-512
>
> Regards
>
> -Markus
>