SSE as a concept logically falls back to long polling quite reasonably (websocket is not as easy to abstract, but plenty of libraries do it).
The main idea is that with SSE it is a backchannel - you use regular URLs (and maybe things like rest) from client -> server, and for getting data - but you have a backchannel for server to realiably tell client that something has changed (message payload may or may not contain the change, client usually will sync). Google wave (ha, anyone remember that?) made use of this (within limits) in a somewhat pre-websocket era. Also - IE ruining the party yet again (yes, it is a fact of life, agree. IE 11 still doesn't have SSE). On Thursday, May 29, 2014 7:01:51 PM UTC+10, 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]>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]. For more options, visit https://groups.google.com/d/optout.
