Yup. As noted, there is a proliferation of c-extensions binding to various event-loop implementations - no "native" one, not until 2014, that is... :)
Still, it shows how doable things are even now for web2py the way it is... I'm not sure if Pypy is relevant to web2py... Can it run on it? I mean, the problem is obviousely that c-extensions for c-python an not run in RPython (Pypy), right? I mean, what is the status about, say, database-drivers? As for ipc use-cases, these are more related to 0mq stuff... External back-end sockets But what I thing most still don't see what I'm seeing, is about SAPs: Look, it doesn't really matter how you turn it around - SAPs are the future, for the most part. It doesn't really matter what protocol is used - web2py needs to be non-blocking/evented in order to ride this SAP wave... One way or another, sessions need to interact - there needs to exist a built-in loop-back path of messages comming from one session and being distributed into other long-standing-sessions for pushing back to their respective clients on the connection they are holding - social-network applications and collaborative-views are on the rise, and server-side frameworks need to adapt accordingly. Currently, there is no way to accomplish this with web2py without threading (which is diabolic in python). The only other way to do that in a single-threaded way, is via an external connection - whether that being a message-queue like redis, or a secondary web-framework that is evented. In the first case, you would need some kind of co-routine implementation in the controller-actions, which would then require some kind of centralized-scheduler for this to be done in a sane way. Some greenlet-based integration is thus a viable option. In the second case, we are talking IPC. Then 0MQ shines, with pub/sub-interoperability with external message-queues or secondary web-frameworks. In a threaded-web2py story, you could implement a pub/sub topology with zmq-sockets that have queues, with threads calling I/O-blocking socket-listeners within controller-actions. But the whole point is to get away from threads... I thing the best approach is to use a combination of simple generator-actions in contollers, in conjunction with non-blocking greenlet'ed-0MQ sockets - this can actually be done today... In either threaded/non-threaded story... You sont even need to monkey-patch all of web2py - just the 0MQ sockets... I just thing that his sould be integrated natively to web2py, as it should be as simple as adding a decorator for controller-actions to make them "async". It should be like any other service-implementation in web2py. The generator-stuff could be part of this integration also, so you could reuse your existing controller-actions without changing the code... -- --- 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.
