On Sunday, April 7, 2013 1:51:11 PM UTC+2, Arnon Marcus wrote: > > As for the Tornado-web-socket example, I looked at the code, and couldn't > figure out how this would work in a production environment... > Does it spawn a separate python interpreter for Tornado? > yes, it's very clear that there are two separate shells.
If so, how does it meld with we2py's controllers? It is unclear how this > works... > none, effectively. it's a separate process that handles just the messaging part..... usually the user's browsers (trough whatever you use, usually a javascript component) asks for messages *from it *or send them *to it* . You can also send messages within your web2py code ..... It's meant to handle all the "messaging" part, leaving the web2py working in the "usual" way. > What serves the Tornado web-app in production? Apache? How? > Tornado usually "stands" by itself. Gunicorn too. Apache doesn't handle well long-standing connection, usually the way to go if you need something in front is using nginx. > > As for the comet file - I can't find it - it seems it no longer exist in > the new version of the web2py source-code.... > ???? comet was referred only in the very first implementation.... web2py.js holds a websocket component. > > As for running web2py via gEvent - how should one deploy this in > production? > with anyserver.py > Can it work with Apache the same way the wsgi-handler does? > Nope. I'm not sure you can find any gevented "something" running behind apache. > Does it require/suggest a "gEvent"ed uWSGI under NginX ? > If you want to run a gevented web2py, *it's another story alltogether*, that's not "pertinent" to what websocket_messaging.py is. BTW, you'd need to "adopt" gevent-friendly libraries, etc etc etc if you don't want to rely just on monkey patching, and code all your app with gevent-like statements if you want to "exploit" the real potential of gevent. > This is all very bewildering... > The documentation is very lacking... > I think you'd need to identify correctly what are your requirements and stop thinking that all of what you want can be achieved in a single-process. Requirements for "threading-like" webserver, "forked" ones can be (with few limits) assumed as "equal" regarding the choosen programming style, but long-standing connections are very different. That's why the messaging part is abstracted away in a lot of implementation: you do what needs to be done in your "normal" environment and leverage the "messaging" with another "component", maximizing the usefulness of an MVC framework and leaving the ultra-specific messaging implementation on something external alltogether, that does just what it's meant for. -- --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
