On 05/28/2014 11:07 PM, Kohsuke Kawaguchi wrote:
On 05/28/2014 01:49 PM, Jesse Glick wrote:
On Wed, May 28, 2014 at 4:37 PM, Kohsuke Kawaguchi
<kkawagu...@cloudbees.com> wrote:
And the problem is that adding more dynamic updates in a modular way
(i.e., friendly to plugins) translates to a lot of separate HTTP
requests, and thus lots of overhead—unless you take care to define a
new API framework for “stuff that may be contributed by various
components and should be bundled in a periodic refresh when out of
date”, which is starting to sound like a crappy reimplementation of
Meteor.
I was mentally picturing WebSocket that allows various scripts inside a
page to subscribe to the events happening on the server. I also wanted
to build client-side representation of the model objects on the server
in the same form as the @Export-ed data model, and allow scripts to
declare the properties that they need through the tree path expression
we use in */api --- when the subscribed event actually happens the
client gets the model that it asked for.
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
--
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 jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
