jsr372-experts@javaserverfaces-spec-public.java.net

[jsr372-experts] Re: [jsr372-experts mirror] Re: [JAVASERVERFACES-SPEC_PUBLIC-1396] f:socket for SSE and WebSocket PROPOSAL

From: arjan tijms <arjan.tijms_at_gmail.com>
Date: Sat, 19 Dec 2015 17:33:36 +0100

Hi,

On Fri, Dec 18, 2015 at 10:28 PM, Kito Mann <kito.mann_at_virtua.com> wrote:

> FWIW, I strongly believe we should support long polling as an alternative
> to WebSocket. JSF is used by lots of big companies that may not be able to
> use WebSocket, and having a reliable fallback is important.
>

Such compatibility is a bit of a double edged sword. On the one hand it's
important to keep users on the system and make sure they can upgrade, on
the other hand it also tends to bloat the platform.

In this case those who can not use WebSocket yet can still use JSF 2.3 but
just for push seek out other alternatives, like the PrimeFaces push.

Also don't forget that Java EE 8 is scheduled for no sooner than ~half of
2017, and if history is anything to go by may even be later. A lot of
vendors take between 1.5 and 2.5 years to implement the new spec (see my
research here:
http://arjan-tijms.omnifaces.org/2014/10/java-ee-process-cycles-and-server.html).
From experience I know companies, especially the bigger ones, take at the
very minimum some 6 months to switch to a new server. Practically I guess
this means big companies won't be using JSF 2.3 in production until ~2020,
and by then WebSocket is hopefully truly ubiquitous.

On the other hand, if you do feel the reliable fallback is absolutely
important, wouldn't it be better to put this in JSR 356? Such fallback
could be beneficial for all WebSocket usage, not just for JSF.

Now as Linda et all mentioned at the Java EE list and elsewhere there is a
resource problem (other constraints on the time of people), but I guess
that could be largely mitigated if you provided all the necessary patches
for a solution. Now I can't speak for the JSR 356 lead of course, but this
typically means a full patch for the RI, a test example on which the TCK
may be based, and the spec text. Normally Oracle would also have to find
resources to do a WLS implementation, but that likely won't be needed here
since WLS already supports a fallback natively.

IMHO, such fallback together with making it legal to instal the WS endpoint
lazily during runtime would make a great MR. What do you think about this
option?

Kind regards,
Arjan Tijms