<f:push/>: Use ServerSentEvents (instead of WebSockets)

[nimo23]

Are there any plans to add ServerSentEvents to JSF Spec?

For example,

<f:sse channel="someChannel" ... />

or

<f:push channel="someChannel" ... />

Currently, I must use <f:websocket>, if I want to send messages from server to client even if I do not need bidirectional connection. I am thinking of an annotation (like @Push) to fire an event to a tag (like <f:push>). Currently, @Push is also registered for JSF Websocket, maybe another name needs to be used.

[BalusC]

The <f:websocket> implementation is by design already unidirectional, from server to client. The other way round should go via <f:ajax>, primarily because of maintaining the JSF view state and HTTP session and, importantingly, being able to satisfy all security constraints on business service methods. None of these are available during an incoming web socket request per-se.

In the early days, during deciding whether to use SSE or WebSocket for the unidirectional push purpose, the choice for WebSocket was made because the spec was at the moment already finished and more robust and supported by a wider range of web browsers.

[nimo23]

The implementation is by design already unidirectional, from server to client.

I think, for use cases needing only unidirectional connections, SSE has some benefit over websocket connections (e.g. no websocket-reconnections, less overhead for maintaining websocket connections, stateless, fire-and-forget,...). Nowadays, SSE is supported well https://caniuse.com/eventsource.

[nimo23]

The implementation is by design already unidirectional,

I think, it would be better to re-implement the f:push to use SSE instead of WebSocket. It would not only fit better to the name f:push but we also have all the benefits of SSE over WebSocket connections (e.g. HTTP/2 multiplexing, standard HTTP, automatic reconnection, stateless, references by event names and ids, etc.).

[NicolaIsotta]

Bumping this. I cannot use websockets in the production environment because corporate firewalls don't like them. I had to resort to polling, so SSE support would be nice, maybe using a new component not to break backwards compatibility? Eg: @SSEPushContext e f:sseListener