I was not trying too, I'm just noticing how much this discussion is > starting to involve a lot of things that are "offtopic". It's one thing > searching for answer (and expecting them) on a specific topic and another > one to try to follow every bit of your proposed > libraries/solutions/frameworks. The more you add to the "offtopic list" the > less people will answer. ... we started from sse and added websockets. then > went to 0mq, that is the only one implementation without a central broker. > Believe me, I'm starting to loose you as well ^_^ >
Point taken. I did want to go over all of these, to see what people have to say. I started with a specific topic, and since I was asked for my use-case, then since this is a thread I started, I gave myself the liberty to derail off-topic. You are right, I should have split these into separate topics. > When I recommended socket.io for full-compatibility, I had discarded > implicitely all other solutions that may be similar cause its the more > complete one and fits nicely with python, given that it's the only > technology where you're able to leverage a wsgi app (though gevent and > gevent-socketio) . > That's good, me too, but I am currently familiarizing myself with this huge world, so my research is broad enough to include whatever is going on, and then checking what implementations exist, and which (if at all) are the "fullest" for python. > That being said, if your interest is "academical" you may as well code > your own new transport in C++. Here on web2py-users I tend to recommend > ready-to-use-and-complete solutions involving both python and the web world > as much as I can, cause it's not the "let's try something new" group :P > Well, none of the options I gave, are ones that don't have a good python implementation - except perhaps the web-sockets javascript frameworks that are mainly for node.js... On the "home page" of engine.io on github. > > *Engine is the implementation of transport-based > cross-browser/cross-device bi-directional communication layer for > Socket.IO <http://github.com/learnboost/socket.io>.* > > that should be the core concept to grasp on a broad-spectrum research, > presentations aside. > You can argue semantics, I think it's irrelevant... An "implementation" is more of a "library" to my ear than a "protocol"... anyways... In my POV, the most pressing argument is that you need to choose either > "single endpoint for messages" or "0mq" .... the latter choice will end up > trimming all the possibilities to one. > > Hmmmm I think I already made that choice, and backed it by examples and use-cases... I am explicitly after a centralized messaging server - as a co-server to the main web2py one. The question is "how will it be structured". It could be: 1. RabbitMQ : AMQP + WebSockets 2. Tornado : 0MQ + WebSockets 3. web2py/gEvent : 0MQ + WebSockets > what I meant is that a very few set of applications need the "realtime > interaction" on the route client --> server.... > e.g. in your "calendaring" example the times the user will receive > messages that supposedly holds the informations about appointments sent by > other clients will be far more than the times the client will send its own > appointment to the server..... > In this usecase you could leverage sse or websockets to receive messages > on the page, and let the client send "in the usual way" to a normal > webserver what is his appointment, then web2py would send that message to > all the other clients passing though the "tornado broker". > I see what you are saying... In fact that was my original idea - I like SSE better for many reasons. But it IS less popular, and has even less browser-support then websockets... For example, last time I checked, it still has a problem with CORS... Most browsers just didn't implement that feature-in for SSE, even though it's in the spec... Also, with the incentive of unifying messaging, I finf there would be more higher-level libraries generalizing 0MQ / AMQP over websockets, then over SSE. For example: http://avalanche123.com/blog/2012/02/25/interacting-with-zeromq-from-the-browser/ Also, I still didn't get a clear answer as to how to implement SSE in web2py... You said that the commet-thing is no longer existing, as "websockets" where already included in web2py.js, which as I remember correctly is referenced in the main application layout. But what about SSE? I mean, sure, it's just an HTTP request, at start, but there is a different model for "responding"... How is web2py built for doing that? Is it keeping the session afloat for that connection, if it get's the correct MIME-type? Will I just be able to reuse the same controller-action for consecutive replies? Can I explicitly call it from another controller, from a different session? Where should a "yield" be placed? There is ZERO documentation about this in the web2py book, and there was only one thread about this in this group, which had an attached "example application" packed in a w2p file that I couldn't use for some reason... Another reason, is that 0MQ / AMQP already implement all the necessary architecture of queues, routing, addressing and subscriptions... Sure, I can "emulate" 0MQ/AMQP semantic-components, by using Redis for "queues", "sessions" for "bindings" and "controller-actions" for "exchanges"... It would just mean me having to write more code, and learn more low-level stuff - and the whole point about these things is that as there are standards and libraries, I should be able to remain-afloat on the higher-level. > saying "they use redis as a message broker" is not the same of saying "it > has ampq support". > Again, researching on the "gist" of the features provided, if you search > for "redis messaging" the first result on google leads to > http://redis.io/topics/pubsub > Obviously I got confused by how the logstash documentation wrote about this... I just didn't get around to checking Redis's pub/sub yet... -- --- 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.
