Question

There is a demo by IBM that shows how easy Reverse AJAX can be used with DWR 2. On the other hand, Scala/LIFT comes with built-in Reverse AJAX capability.

1. Question: Any experience if this works fine with Spring MVC?

2. Question: If you’d start from scratch, what are the pros and cons for preferring Scala/LIFT over DWR/Spring MVC

3. Question: In Scala/LIFT, is the security handling as sophisticated as in Spring Security?

Answer 1

Lift’s Comet Architecture which was selected by Novell to power their Pulse product after they evaluated a number of different technologies.

Lift’s Comet implementation uses a single HTTP connection to poll for changes to an arbitrary number of components on the page. Each component has a version number. The long poll includes the version number and the component GUID. On the server side, a listener is attached to all of the GUIDs listed in the long poll requests. If any of the components has a higher version number (or the version number increases during the period of the long poll), the deltas (a set of JavaScript describing the change from each version) is sent to the client. The deltas are applied and the version number on the client is set to the highest version number for the change set.

Lift integrates long polling with session management so that if a request comes into the same URL during a long poll that would cause connection starvation, the long poll is terminated to avoid connection starvation (some browsers have a maximum of 2 HTTP connections per named server, others have a max of 6). Lift also supports DNS wild-carded servers for long poll requests such that each tab in the browser can do long polling against a different DNS wildcarded server. This avoids the connection starvation issues.

Lift dynamically detects the container the Servlet is running in and on Jetty 6 & 7 and (soon) Glassfish, Lift will use the platform’s “continuations” implementation to avoid using a thread during the long poll.

Lift’s JavaScript can sit on top of jQuery and YUI (and could sit on top of Prototype/Scriptaculous as well.) The actual polling code includes back-off on connection failures and other “graceful” ways of dealing with transient connection failures.

I’ve looked at Atmosphere, CometD, Akka (all JVM-oriented Comet technologies). None had (at the time I evaluated them) support for multiple components per page or connection starvation avoidance.

Novell started from scratch and chose Lift to power Pulse for some very good reasons.

In terms of security, Lift beats Spring + Spring Security hands down. See http://www.mail-archive.com/[e-mail]/msg13020.html

Basically, Lift’s security is baked into your application. Lift apps are resistant to common problems (cross site scripting, replay attacks, cross site request forgeries) by default. Lift apps are resistant to parameter tampering by default. Lift’s sitemap defines site navigation and access control rules. This means you never have a link that someone can’t click on. You don’t need to have an external filter (e.g., Spring Security) that you have to configure independently from you app (whoops… moved a page, but forgot to make sure the Spring Security XML file was updated.)

Oh… and if you don’t want to use a templating language, here’s a complete Lift Comet chat component:

class Chat extends CometActor with CometListener {
  private var msgs: List[String] = Nil

  def registerWith = ChatServer

  override def lowPriority = {
    case m: List[String] => msgs = m; reRender(false)
  }

  def render = {
    <div>
    <ul>
    {
      msgs.reverse.map(m => <li>{m}</li>)
    }
    </ul>
    <lift:form>
    {
      SHtml.text("", s => ChatServer ! s)
    }
    <input type="submit" value="Chat"/>
    </lift:form>
    </div>
  }
}

And to insert this into a page: <lift:comet type="Chat"/>