Web Sockets support in Lift

[David Pollak]

Folks,

I want to publicly reiterate that Lift will support web sockets for Comet transport and other features in Lift.  However, we're going to wait until the web sockets protocol and API is closer to standardization and maturity.  This article: http://news.cnet.com/8301-30685_3-20025272-264.html?tag=topStories1 points to one of the many issues related to web sockets.

So, it'll be a little while before the web sockets guys settle on a unified solution, but rest assured that Lift will support web sockets and your CometActor code will not need to change one little bit to support it.

Thanks,

David

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Blog: http://goodstuff.im
Surf the harmonics

[Heiko Seeberger]

Sounds great!

Heiko

> --
> You received this message because you are subscribed to the Google Groups "Lift" group.
> To post to this group, send email to lif...@googlegroups.com.
> To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
>

--
Heiko Seeberger

Company: weiglewilczek.com
Blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net
Akka - Simpler Scalability, Fault-Tolerance, Concurrency & Remoting through
Actors: akkasource.org

[Marius Danciu]

Interesting stuff. Thanks.

[David Pollak]

There's been no compelling use case for web sockets... no use cases where the existing long polling is not as good or better than web sockets, so there's no reason to prioritize the transport of comet over web sockets as something to implement in Lift.

On Wed, Dec 5, 2012 at 2:54 AM, Arsenij Solovjev <xepe...@gmail.com> wrote:

Folks,

I want to publicly reiterate that Lift will support web sockets for Comet transport and other features in Lift.  However, we're going to wait until the web sockets protocol and API is closer to standardization and maturity.  This article: http://news.cnet.com/8301-30685_3-20025272-264.html?tag=topStories1 points to one of the many issues related to web sockets.

So, it'll be a little while before the web sockets guys settle on a unified solution, but rest assured that Lift will support web sockets and your CometActor code will not need to change one little bit to support it.

Thanks,

David

Not to necrothread, but has anything happened in this direction since this post?

Cheers,
Arsenij

--

--
Lift, the simply functional web framework: http://liftweb.net

Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code
 
 
 

--

Telegram, Simply Beautiful CMS https://telegr.am

Lift, the simply functional web framework http://liftweb.net

[SK]

Hi,

I strongly support the lift community's reluctance to add support for WebSockets before it is better supported in servers (with JSR-365) and all major browsers (IE10).

However there are two compelling (at least for some) features that comes with WebSockets:

* Less overhead - No need to process so many headers and do not have to wait for another connection to reappear to push more date. If a client does lots of connections that might be a performance problem. In that respect WebSockets might improve overall performance. However I believe that WebSockets should only be used when you need duplex communication. To only push data I would say the EventSource technology should be considered.

* Number of HTTP connections per server - Lift does an amazing job handling multiple comet actors on a given page (I got 11 on one page and that works great). There is still a limit (I guess 6 is the default for IE8 and others browsers got other limits). In some applications it is natural to have several pages up at the same time. As each page has its own comet connection the limit of e.g. 6 in IE is reached quite often. The effect is lots of short lived connections the server. IE is putting up and taking down connections at an amazing rate. I don't think the WS protocol have such limits and that might be a compelling reason to investigate WebSockets further. In Gecko the limit is 200 (https://developer.mozilla.org/en-US/docs/WebSockets).

I'm not saying that you should adopt WebSocket but it might be a good fit for some Lift use cases. 

Stein Kåre

- Hardly using LIft anymore but it's a very interesting community to follow

[David Pollak]

FWIW: Lift multiplexes all the CometActor connections through a single HTTP request. Lift aggregates multiple responses per HTTP request if there are multiple responses available. Lift does server-side connection counting and will turn long polling connections into short polls if the connection count could result in connection starvation (this is done on a browser-type by browser-type basis.) Lift also supports wildcarded host names for the long poll connection so that each long poll is against a different host so the connection count cannot cause starvation.

Lift's Comet implementation, even using long polling, is so much better than any other web framework's push stuff, it's not worth comparing. With the multiplexing, you don't worry about putting a lot of components on a page because they all go through a single HTTP connection. The connection starvation detection done at the framework level, so it's uniform across the application and does not have to be repeated in user code. The partialUpdate versioning means that even if there's transient connection loss, the updates will be sent correctly and in order when the connection is re-established. Etc.

I agree that EventSource is a nice choice for server-push and at some point, I'll probably put the code in to detect the browser type and use EventSource if it's available.

But my reluctance to Web Sockets is based on the actual real-world use case. There's plenty of talk about the perceived potential nominal performance characteristics of long polling vs. web sockets. But nobody's ever published a benchmark comparing the CPU load, the update frequency, etc. documenting that Lift's mechanism is materially worse than web sockets. If someone does that... puts together an actual real world use case demonstrating why web sockets are really better than the existing mechanism (and this isn't a microbenchmark, but something that is done across the Internet through Nginx or HA Proxy, etc.), then I'll consider putting in the work.

But at this point, I see Web Sockets as the shiny buzzword that people like... but at the end of the day, they want to push changes from the server to the client. Lift does that and has been doing that to browsers from IE6 on very successfully for 6 years. I'm not opposed to doing new things (heck, I'm burning down a lot of Lift for Lift 3.0 as well as going whole hog on Scala 2.10 only with Lift 3.0) when there is a reason. There's no actual real documented reason to look too much at Web Sockets.

Put another way, people want a solution and Lift's implementation of the solution that people want (push) is extraordinarily good and well tested.

[SK]

@David: well said! I'm rally looking forward to see what you have removed from lift in 3.0. That is where you'll see the real value/maturity. Adding is easy. Removing is hard, but it's really important.

SK

[Grant]

David,

I assume you've seen this benchmark:
http://webtide.intalio.com/2011/09/cometd-2-4-0-websocket-benchmarks/

What were your thoughts on it? I've no idea how cometd compares to lift's comet, of course.

/Grant

[David Pollak]

Do have you run the same benchmark for Lift? Keep in mind what I said about Lift's comet implementations vs. every other Comet implementation I've seen (and that includes CometD which has never impressed me).

[Grant]

No I have not run any benchmarks against Lift, though I will be doing so next month. I just found the above results impressive.

/Grant

[Diego Medina]

Something else to consider is the developer tools support. Today I was
using this site
http://www.websocket.org/echo.html
And Firefox / firebug does not show any information about the data
sent from the server back to the browser(I just started looking into
this, so maybe there are other plugins that do help)
Using Chrome, there is a Network -> Websocket tab, but to see new
events, you need to click out of the inner "Frames" tab and back on
the request to see new data come in.

This in contrast with debugging Lift's comet requests, which you can
see all kinds of info on pretty much any dev tool.

Just something to consider too.

Thanks

Diego

Diego Medina
Lift/Scala Developer
di...@fmpwizard.com
http://www.fmpwizard.com

[Parakrama Dharmapala]

Hi Guys..

I've been searching on the Internet to find some up to date information about Lift's support for WebSocket. Searching seems not giving me anything.
Is there any updates for this subject?
--
Regards
Parakrama Dharmapala

[Diego Medina]

No news. Do you have any use case where the current long poll implementation doesn't work?

---

You received this message because you are subscribed to the Google Groups "Lift" group.

To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Diego Medina
Lift/Scala consultant
di...@fmpwizard.com
http://blog.fmpwizard.com/

[ti com]

may I suggest a "use case" --- where you're doing things way that is common, that the backend is more of an API and you have javascript developers do the frontend, and for them it's easier to use the standard web sockets apis

or like if you want to use this https://subvisual.co/blog/posts/39-tutorial-html-audio-capture-streaming-to-node-js-no-browser-extensions

[David Pollak]

Lift provides a wide variety of single-JavaScript-call streaming communications mechanisms between the browser and the server including Streaming Promises (see http://lift.la/blog/roundtrip_promises) and client/server Actors. Lift abstracts the transport away.

So, once again, if you have a use case that Lift's push mechanisms are not satisfying, we can take a look at them, but in the 5 years that people have been asking about Web Socket support in Lift, nobody has actually come up with a use case that's not already covered by with Lift has today (and has had for 5+ years).

Twitter: http://twitter.com/dpp

Lift, the simply functional web framework http://liftweb.net

Blog: http://goodstuff.im

[David Pollak]

Oh... and here's a presentation on and code for integrating Lift and Clojure with client and server actors. Not only is it simple to call Lift's code from JavaScript, it's simple to call it from ClojureScript.

[Antonio Salazar Cardozo]

Of note, I've recently seen people mentioning that they've abandoned Web Sockets

to go back to long polling due to its comparative resilience to transient connections.

So… There's that. I would argue that 95+% of the time the differences don't matter

at small scale anyway.

Thanks,

Antonio

To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Diego Medina
Lift/Scala consultant
di...@fmpwizard.com
http://blog.fmpwizard.com/

--
--
Lift, the simply functional web framework: http://liftweb.net
Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code

---
You received this message because you are subscribed to the Google Groups "Lift" group.

To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
--
Lift, the simply functional web framework: http://liftweb.net
Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code

---
You received this message because you are subscribed to the Google Groups "Lift" group.

To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Twitter: http://twitter.com/dpp
Lift, the simply functional web framework http://liftweb.net

Blog: http://goodstuff.im