On Sunday, April 7, 2013 6:25:06 PM UTC+2, Arnon Marcus wrote: > > How about engine.io? or SockJS?
as I was saying, you're reading too much too soon, just naming buzzwords without actually **thinking** to what you need. Engine.io is just the "protocol" for socket.io. Sockjs is another abstraction layer on top of websockets, has the same exact agenda of socket.io (with a bit less of flexibility) > Most libraries have fallbacks/pollifills/shims or whatever... > read it all carefully. the one "whatever" is not there, you have to code it yourself. World is full of "that was the right tool until I needed that extra bit" :P > > 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: > A "centralized broker" is a thing that (eventually) store messages and route them where you want them to go. All of the proposed solutions, included websocket_messaging.py, take care of that. > 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... > It's not where you need to commit the central-point. The point of messaging is where your messages need to be originated and where they need to go. Additionally, you have to check if what you want to do is feasible with the tech you choose. Store what needs to be stored is a layer on top. > > 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. > so you say.... the solution can be very well be a normal webserver serving the pages and a non-blocking one to be the message-passer. > For use-case 2 - The best solution is a dual-fronting (SSE + 0MQ) and a > connection to the database. > Don't know a single bit of what you'll use to code your desktop app. Given that you have to rely on connectivity I really won't go for a desktop client that basically does what your browser application does already. > 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... > > read it again. It has pub/sub support, but no AMPQ whatsoever, although you can find libraries that on top of it abstracts away the difference. -- --- 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.
