Perhaps I should have mentioned it more explicitly, but I was only thinking about using it to do updates after the initial page load, with most of the server-side initial HTML rendering intact.
So when WebSocket/SSE/etc does not work, all you lose is the dynamic update, which I think is acceptable loss.
On 05/29/2014 02:01 AM, teilo wrote:
Just so people are aware IE has no support for SSE[1]. IE is still commonly used in enterprises despite it many and continuous flaws. So far Jenkins has been pretty browser agnostic. /James [1] http://status.modern.ie/serversenteventseventsource On Thursday, 29 May 2014 08:26:38 UTC+1, Tom Fennelly wrote: On 29/05/2014 02:57, Michael Neale wrote:On Thu, May 29, 2014 at 11:33 AM, Christopher Orr <[email protected] <javascript:>> wrote: It may also be worth considering Server Sent Events — basically one-way "push" from the server, without all the handshaking and protocol upgrade fun of WebSockets. Could be useful if clients are just listening for server updates, without sending anything (as is generally the case today). Last week I wrote a quick experimental plugin to stream log events as they happen via SSE to remote JavaScript clients for any running build; I was surprised how simple it was to build.. (Though I just noticed that it has less support than WebSockets (thanks, Microsoft): http://caniuse.com/eventsource) Chris +1 on SSE. I have a fair bit of experience with websockets on servers - enough to know that almost no one gets their proxies right - and it is a source of complaints. SSE seems to work better out of the box, alternatively long polling/comet can also work (a given jenkins master doesn't have to scale to 10s of thousands concurrent users, which is the assumption for a lot of other web choices). Having said that, nearly halfway through 2014 websockets is probably not a controversial choice and does open up a lot of other options. If someone is accessing their jenkins via a proxy, ssl and careful configuration is required to support http upgrade and not break websocket too.AFAIK... any proxy/gateway between the websocket client and server needs to be pretty much websocket aware. SSE would seem like a perfect fit for Jenkins since the client is listening only (not sending back to the server - could implement that on top anyway if needed). As far as I know SSE is a fancy long poll/comet style protocol and so would require the same considerations re number of concurrent users. -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected] <mailto:[email protected]>. For more options, visit https://groups.google.com/d/optout.
-- Kohsuke Kawaguchi | CloudBees, Inc. | http://cloudbees.com/ Try Jenkins Enterprise, our professional version of Jenkins -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
