Hello Arnon, I am very interested in the things you are suggested. I do not think web2py will be an async framework because in order to make an async component in Python we need to waif for 3.4. I do not think we have a choice.
The problem with building an async framework are: 1) scalability (how to you deploy many servers behind a load balancer and make them work together) 2) security (it can be done but it would be different than web2py's). 3) most of the code runs client side (ember.js) so why build the server in Python at all? A good case must be made. Perhpas the JS should be generated from Python? On Tuesday, 16 April 2013 15:52:07 UTC-5, Arnon Marcus wrote: > > This way, it could be future-proofed. As web2py looms, and 2014 arrives, > you could only need to modify the internals of this integration, to support > PEP380 (Python 3.3's "yield from") and/or the higher-level Tulip > implementation (Python 3.4) - All without breaking existing code - The > controller-actions would still use the same decorators-syntax - it's just > their back-room implementation that would be different. > > Here is what is being done today that can be implemented, even for web2py > 2.x: > http://www.youtube.com/watch?v=wLLHv5GbZiQ > -- --- 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.
