I too can see a need for polling or long-polling using XMLHttpRequest. However, I don't consider keeping a GET request persistently open, misusing it to push updates back, as particular beneficial or scalable?! Perhaps you are talking about some other mechanism in HTTP, in which case, can you point me to a RFC?
/Casper On Sunday, September 9, 2012 11:03:28 AM UTC+2, fabrizio.giudici wrote: > > On Sun, 09 Sep 2012 09:56:26 +0200, Casper Bang > <[email protected]<javascript:>> > > wrote: > > > I'd have to agree with that approach, but I'd also try to explain a bit > > more about why. > > > > Traditional web frameworks try to do too much emulating classic MVC/MVP > > > and > > ends up not doing a very good job at all, adding countless > > abstraction layers like life-cycle management, session management, > > templating, expression language etc. Some later hybrids like GWT tries > to > > unify the experience further, by pushing state and business logic out on > > the client. However, cross-compiling and shielding the developer further > > only gets you so far - eventually you end up acknowledging the > undeniable > > truth, that the web consists of a server delivering content to a client > > which is then rendered via HTML/CSS and JavaScript! > > > > By writing your application backend as a stateless REST service, and > > hooking some arbitrary application layer on top of these, you've set > > yourself up for success down the line. The backend need only consist > > of glorified servlets, that can be replaced by any other HTTP technology > > if/when desired (I.e. Jersey/JAX-RS replaced by node.js). By being > > stateless, it can scale horizontally rather than vertically. By having a > > clear responsibility (serving up data) it can be configured as per an > > aspect fashion with various filters in front (caching, compression, > > security, conversion, auditing, logging etc.). By being detached from > the > > frontend, it can be reused by other frontends or even as a B2B gateway > > (I.e. Mobile JQuery for smartphones, native smartphone frontends etc.). > > Hell, it can even form the basis of a unified data engine complete with > > query language and AST optimizer for extracting and transforming data > > from > > the underlying resources (I.e. the OData protocol) without some clunky > > ORM. > > > > Jersey + JQuery (Mobile) is hard to beat in regard to maintainability, > > flexibility and performance. Keep it simple, use Java where it makes > > sense, > > but don't aim for the world to be completely wrapped in Java as is the > > traditional conservative pseudo-religious view of many. :) > > I like this analysis, but it's incomplete from my point of view. The > criterium I use to distinguish web frameworks that I might like or not is > > the presence or absence of push updates. Actually, when you write "the web > > consists of a server delivering content to a client", the problem is that > > it often does with a pull approach, which to me imposes too severe > limitations to design, as harmful as those unnecessary life-cycle > complications etc... Of course the web 2.0 can do pushes with different > implementations, that I don't care of and I dont' want to care of. I want > > my framework to support it. From this point of view GWT is superior, but > with the cited cost of development complexity. Vaadin is an excellent > trade off (the cost to pay is to accept client-server interactions for > almost everything you do in the client). If you want push updates, a > (glorified) servlet is not enough. > > > -- > Fabrizio Giudici - Java Architect, Project Manager > Tidalwave s.a.s. - "We make Java work. Everywhere." > [email protected] <javascript:> > http://tidalwave.it - http://fabriziogiudici.it > -- You received this message because you are subscribed to the Google Groups "Java Posse" group. To view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/LWxmWFs98W0J. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
