On Sunday, April 7, 2013 9:23:16 PM UTC+2, Arnon Marcus wrote: > > Don't wan't to start a flame-fest, but I feel like I am under fire here, > and unjustly so... > > 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. 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 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
> as I was saying, you're reading too much too soon, just naming buzzwords >> without actually **thinking** to what you need. >> > > I admit I don't have experience with many of the things I was writing > about, but I don't think I am ill-informed or have erroneous-understanding > of things. I made a broad-spectrum research, and wen just deep-enough into > any component-option to get the "jist" of it, and see what it's all about. > 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. > Here you lost me completely... > Obviously the main part of messaging is the routing-topology - I am well > aware of that. > But if I architect the components in a way that clients communicate > among themselves with no centralized location, it would be sub-optimal for > storing the message's data from disparate places - It would mean more hops > in the message rout, and might even eventually mean coding the "storing" > code in multiple places. If I have a centralized message-broker, it may > include in it's topology, a filtering of which messages should be stored > and where, and may have, for example, a dedicated queue for an out-going > channel that goes out to store the data - this way it may even be > aggregated before submitting the request to store the data, so there would > be less database traffic down the line. > 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 ^_^ 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. > What I mean by that, is that if the non-blocking server for the messaging, > that would also do the routing-topology, would be just another web2py > server, running via gEvent, it can do the database-commits by itself. And > since it is web2py, I could reuse the DAL code I have in the model of the > main one - so I would not have learn a new ORM system, or device a channel > for talking to the main web2py just for the database-commits. > 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 got that impression from this: > http://logstash.net/docs/1.1.1/tutorials/getting-started-centralized > > Logstash treats Redis as a message-broker - with output messaging - I > don't know how exactly... > 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 -- --- 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.
