On Jan 6, 6:44 pm, David Pollak <feeder.of.the.be...@gmail.com> wrote:
> On Wed, Jan 6, 2010 at 7:17 AM, Paul Sandoz <paul.san...@sun.com> wrote:
>
> > On Jan 6, 2010, at 3:22 PM, David Pollak wrote:
>
> > On Wed, Jan 6, 2010 at 5:23 AM, Timothy Perrett 
> > <timo...@getintheloop.eu>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?
>
> Yes and it will be supported by the work Marius is currently doing.
>
>
>
>
>
> >> 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.
>
> To date, the large Lift comet users have been using Jetty with success.  If
> there is demand for Lift's Comet support on non-Servlet 3.0 platforms, we'll
> look into Atmosphere integration.


With the suspend/resume decoupling/abstraction that is in progress
(the first phase is done and awaiting committer's approval on
reviewboard) should be quite easy to allow such integration. Next step
is to implement Jetty 7 support.

>
> Thanks,
>
> David
>
>
>
> > Paul.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Lift" group.
> > To post to this group, send email to lift...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > liftweb+unsubscr...@googlegroups.com<liftweb%2bunsubscr...@googlegroups.com>
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/liftweb?hl=en.
>
> --
> Lift, the simply functional web frameworkhttp://liftweb.net
> Beginning Scalahttp://www.apress.com/book/view/1430219890
> Follow me:http://twitter.com/dpp
> Surf the harmonics
-- 
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.


Reply via email to