Just notices, I was writing SAP instead of SPA the whole time... :) I get what you are saying - the underlying unspoken agenda here, is this : "Web2py should remain Pure-Python in it's default implementation" This places us on a discussion that is assuming a threaded-deployment, as it is also the default-implementation that would be publicized. So, we then any argument about using evented-single-threaded deployment, is no longer relevant within the boundaries of this discussion. In this case, we inevitable going to refer Tornado, which IS ALSO a pure-python implementation, and yet is doing non-blocking-I/O, by using threads. The way I saw it in Tornado, it is wrapping async-style code that is abstracted away from the developers -cClasses of a kind they call "YieldPoints" (Callback, Task, Future): http://youtu.be/4Ztq-Yz1ero?t=40m57s * Guido has basically "stolen" these classes for Tulip...
So essentially, if you run web2py on-top of tornado's I/O-loop, you should be able to use these YieldPoint classes within the controller-actions. The question that remains open to me is, can you do it even "without" tornado's I/O-loop... (?) If you can, than it should be relatively straight-forward to implement a service that wraps around these classes, and "decorate" controller-actions with it. If you can't, than we are in a plugin/contrib story.. Can it include a "service"? Really, what I am simply asking could be expressed and answered-for by a simple service... Can a plug-in/contib be a web2py-service? -- --- 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
