Do you mean the meteor framework or the "comet" long poll convention?
On Thursday, May 29, 2014, Kohsuke Kawaguchi <[email protected]> wrote: > On 05/28/2014 01:49 PM, Jesse Glick wrote: > >> On Wed, May 28, 2014 at 4:37 PM, Kohsuke Kawaguchi >> <[email protected]> wrote: >> >>> This is also an area where plugin config files are shielded from the raw >>> HTML tags through taglibs >>> >> >> Well, only insofar as they choose to use those taglibs. In most cases >> they do, but there are some places where plugins add raw <tr>s where >> they expect to be inside a <table>. >> > > We'll check this with git-grep. I agree this is an issue, and I've done > this myself before, too, but I still think it's manageable --- by combining > (1) adding additional tags to let those plugins avoid the direct <table> > use , (2) intercepting HTML generation at a lower level in Jelly to notice > out-of-place table generation and correct it, and (3) convincing ourselves > that it's not the end of the world if we end up breaking a few plugins > given the need for changes like this. > > > more dynamic content update in real time without page reloading. >>> >> >> It would be nice (especially if we can finally kill Auto Refresh!), >> but you have to be very careful about the performance impact. >> ajaxBuildQueue and ajaxExecutors already impose a significant burden >> on the server when a lot of people are holding pages open. Anyone >> proposing to add *more* AJAX stuff had better promise to fix the >> performance of what is already there first. Being able to collapse >> these widgets is fine but they are expanded by default and there is >> currently no way to leave them expanded yet impose minimal overhead. >> >> 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. > > So if one script wants jobs[displayName,url] and another wants > jobs[url,result], at runtime we can mechanically combine them to be > jobs[displayName,url,result] and that's what the client gets. > > I don't know much about Meteor if this is starting to sound like one. > > -- > Kohsuke Kawaguchi | CloudBees, Inc. | http://cloudbees.com/ > Try Jenkins Enterprise, our professional version of Jenkins > > -- > You received this message because you are subscribed to a topic in the > Google Groups "Jenkins Developers" group. > To unsubscribe from this topic, visit https://groups.google.com/d/ > topic/jenkinsci-dev/zDaX4yiWLLw/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- Michael D Neale home: www.michaelneale.net blog: michaelneale.blogspot.com -- 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.
