On Jan 6, 2010, at 3:22 PM, David Pollak wrote:
On Wed, Jan 6, 2010 at 5:23 AM, Timothy Perrett <[email protected] > wrote: Yes, if you constantly change containers, then there is value in Atmosphere for that as it does leverage the native APIs for the container. We [lift] are waiting for servlet 3.0 to standardise the comet API - whilst its debatable if that will prove as an api standardisation solution, it should level the playing field somewhat - right now the different containers are all doing different things in different ways.Marius is actively working on an abstraction of the thread dropping so that other containers that use different APIs can be plugged into Lift (or vice versa) because the Servlet 3.0 spec is taking forever.
OK. Servlet 3.0 spec is now finalized, meaning there is at least one implementation (in GlassFish v3) but i guess it may take time for others to arrive.
Are the async features of Servlet 3.0 sufficient for lift's requirements?
Essentially lift uses special classes within Jetty (the continuation API) to make comet scalable... there is nothing stopping comet working in other containers with lift, the only restriction is that it does not use the native container API so it's essentially thread based - to that end, if you have a lot of connections things could get sticky.Lift has things that Atmosphere does not have (yet) like the multiplex support, and object delta'ing... perhaps other comet frameworks will get this in the future, but right now, using Jetty is not a deal breaker for most of our users. I guess its only really an issue if you have a heavy investment in something that is not jetty. However, I would stress that lift is an excellent framework even if your not using comet and that would of course deploy without any issues in any container.As Tim points out, Lift has a number of advantages in its Comet support: Multiplexing -- you can have many Comet components on a given page and they all talk over a single long poll. You can see this at http://demo.liftweb.com . Both the clock and the chat component are Comet. Neither piece of code was special or required knowledge of the other. Connection saturation detection -- Lift will avoid connection saturation by only allowing a single long poll to be active at once. If a second connection (this is tunable and it's on my to-do list to make it browser tunable as Chrome has more than 2 connections per server) is opened from the browser, Lift will automatically terminate the long poll. DNS wildcard support -- To avoid the connection saturation issue, you can have the long poll done on a DNS wildcarded server and tune the long poll connection termination logic. This allows many different browser tabs to have open long polls. The server name is automatically changed on each page reload and the actual client-side and server-side components are unchanged (that means the app developer doesn't have to worry about this part of the plumbing.)
I am not suggesting Atmosphere can or should be utilized as a replacement for the useful features you enumerate. I think the area where Atmosphere can provide value to lift is scalable async support for many Web/App servers.
Paul.--
You received this message because you are subscribed to the Google Groups "Lift" group.
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/liftweb?hl=en.
