Sounds like a plan then, Kito can you initiate the talks to see if it's
possible to start a JSR 356 MR and offer to do the work for at least the
fallback?
On Mon, Dec 21, 2015 at 1:27 PM, Bauke Scholtz <balusc_at_gmail.com> wrote:
> FWIW: I'd definitely love to see the possibility to lazily install WS
> endpoint during runtime. This appears to be possible given that it just
> works fine in Tomcat and Undertow. Only Tyrus throws an illegal state
> exception (because this indeed contradicts WS spec). This would save us
> from requiring a context parameter. Just the occurrence of a <f:websocket>
> in a JSF page would have been sufficient.
>
> Cheers, B
>
> On Sat, Dec 19, 2015 at 5:33 PM, arjan tijms <arjan.tijms_at_gmail.com>
> wrote:
>
>> 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
>>
>>
>>
>>
>>
>>
>>
>