Don't wan't to start a flame-fest, but I feel like I am under fire here, and unjustly so...
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. > Engine.io is just the "protocol" for socket.io. > I have watched a presentation of the guy who wrote these components. He defines engine.io to be the "core" of a new version of socket.io that is in the works. I watched another presentation by the guy who wrote SocketStream (a light-weight inter-connect layer for server-and-client for node.js), and he said his framework is built upon socket.io, but that he is probably going to "replace" that with engine.io - which would make sense correlating with the other presentation. It suggest a linear-progression - socket.io = mature but might be bloated/have things he does not necessarily need, and engin.io = a newer core that is being extracted out of the older socket.io for use-cases that want more flexibility and control with less higher-level features. > Sockjs is another abstraction layer on top of websockets, has the same > exact agenda of socket.io (with a bit less of flexibility) > I know that, that's why I said I would have to choose between the two. > > 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 > I mean that from what I gather, SockJS initially had no fallback-strategy for older browsers, which makes socket.io a better choice for cross-browser compatibility - from what I hear this is changing, or has already changed. You might argue for "writing yourself" the stuff that you need "extra" from a library, but I don't see a strong-enough argument for saying the same thing about cross-browser compatibility - I don't think I should write "that" myself... As for writing stuff myself, sure, I could do that. But why re-invent the weal ? Sure, if I find something I need that is not supported in a library, I might choose to extend it, or choose another library - I would try any of those before writing my own library though... I don't think there is anything wrong with starting with an existing library, and "gradually" finding out it's limitations "as the need arises" and do the necessary refactoring "if and when is needed" - I think it's a sane and logical strategy - not to mention efficiant and economical - saying that I "might" get stuck because of a library, so I might as well write my own, sounds like "premature optimization" to me... You could take that argument all the way, and write an operating system yourself... Good luck with that... > 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. > This I really don't understand... By "centralized" I meant "a single place that has the routing code to maintain". If I use websocket_messaging.py, AND I use 0MQ on another server, it means I have two codes dealing with message-routing in 2 different places. I would rather them exist in a single place so I can build the routing-topology as a single-layer on-top in a single place. If, for example, I go the RabbitMQ way, it has support for web-sockets as well, so I would guess it can centralize topology-definition for me, for both protocols. I know that 0MQ is a Broker-Less topology, so wherever I put a 0MQ socket, that same place would "ideally" rout messages for both 0MQ-sockets and web-sockets. Both protocols, in this case, are topology-neutral, and low-level enough, so I can build a layer on-top that defines the topology for both (which targets should be fan-outed, which sup/sub'ed, who is currently subscribed to which channel, etc.). Because 0MQ, as oppose to AMQP, is a "library", and not a "protocol, the topology definition is done in code anyways... So where for AMQP, I would define it in, say, XML format or something, for 0MQ I am goiing to "write" the topology myself in any case. Granted, as it is a broker-less architecture, I would have to define it in many "clients", but I can "simulate" a broker if I choose to, so I would rather do that if I build a centralized messaging server. 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. > 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. > 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. > 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. 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. > As I said, it's also a CMS (content-management-system), so we have in my work-place a few desktop-applications that we write plug-ins for version-control and task-pipelining, so all the file-paths that the plug-in saves, are generated and stored at the main web2py application. We also want to make a way for our workers to "chat" from within the desktop-app, through the same web2py app. Think of it like an ALM story - like Mylyn for eclipse, or the similar task-server for visual studio - you have workers working within a desktop app, but collaborating on the same project through a centralized server, via tasks and task-comments. > > 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. > 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... -- --- 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.
