How about engine.io? or SockJS? Most libraries have fallbacks/pollifills/shims or whatever...
The thing is, it seems I would need some kind of centralized broker, if I want to share the messaging code across all use-cases, and I DO want the messages committed, in most cases, so I am not looking for a "direct" browser-to-browser channel: 1. Browser<->Browser : Commit all traffic to the database (pua/sub-chat AND collaborative-views) 2. Browser<->Desktop-App : Commit all traffic to the database (pua/sub-chat only) 3. Desktop-App<->Server (RPC/REST) : Don't commit anything to the database... So, It seems that: For use-case 1 - The best solution is a non-blocking web-server with SSE and a connection to the database. For use-case 2 - The best solution is a dual-front-end (SSE + 0MQ) and a connection to the database. For use-case 3 - I only need a 0MQ for web2py, or falling back to xmlrpc/jsonrpc/REST... As for caching, I think I would need Redis as a stand-alone "third" service... I think I read somewhere that is has some kind of messaging support by itself - acting as a proxy... I think AMQP was the protocol... What do you think? -- --- 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.
