and then there was nodejs :(
2013/4/16 Niphlod <niph...@gmail.com> > >> But my point is that PEP380 in Python 3.3 is already a very solid basis >> for building event-loop kind of web-framework with non-blocking-IO that are >> single-threaded... >> > > It's just a PEP describing how to interact in an eventloop. That being > said, python misses just the wsgi hook (read: a unique way to interact with > all different implementations) to make it usable. It's not web2py's job to > be the next event-looped webserver. > > >> >> The current recommendation for production-deployment of web2py is Apache, >> which (as I understand it) has it's mod_wsgi spawn a python-thread for each >> request. This has all the performance-penalties **mentioned in the first >> video I posted (relating to the GIL), in addition to the famous 10K barrier >> of machine resource and system-thread-limits. >> > > Whaaaaat ? if this is reported somewhere please point it out, we'll remove > it ASAP. Apache with mod_wsgi is a resource-hog that right now has far > better counterparts. Here too, that being said, if there's an apache > instance managing something else in your stack, then it could be useful to > run a python webserver in it, but it's the only case. > > >> Saying that Rocket and Cherrypy are the main focus, is irrelevant. >> It may stay like that for educational/experimentation **use-cases, but >> it has no relevance to production-deployments. >> > > Glad we agree that web2py is not meant to be used only in threaded > webservers. > > >> >> But I think the main thing that bugs me is that whenever I start talking >> about asunc and non-blocking-I/O in this group, everybody immediately >> assume I am just talking about either front-end web-serving, or back-end >> database-connections... I am considering I/O as also being ipc or even >> in-proc communications - having web2py able to communicate with other >> server-side services, and/or different connection-sessions within itself >> for "push" enabled "collaborative" use-cases (whether being based on WS, >> SSE, LP. or any other...). I am talking about transforming web2py's >> internals to being async/event-loop capable, within a single-threaded >> deployment story. >> > > > It is frustrating to me that people are not getting this message... This >> IS the direction that web-development is moving into around the world, and >> if web3py will not keep up with this trend, it may not even see the light >> of day before being left in the dust of history... And I would deem that a >> very sad day for all of us... Web2py is keen on backwards-compatibility - >> web3py is not - so it is an opportunity for restructuring some internals >> and joining web3py with the rest of the second-decade of the 21's >> century... (if not spear-heading it...) >> >> > But your are missing that you didn't present any large usecase for that > (meaning IPC in general, not related to the web client-server patterns). > > "IPC" is just something you agree on your stack to be the common ground. > There's no way you'll find, e.g., Erlang talk to Python through their > respective native APIs, neither Python to Node's javascript modules. > > Given that there are a lot of choices on the "external to both", we're > back to the beginning: it's far more productive code your own > information-exchange-messager than come up with a silver-bullet > implementation that fits all IPC paradigms, and force web2(3)py users to > have that particular tech in their stack. > > -- > > --- > 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. > > > -- --- 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.
