> I have no idea what you are trying to say there. > > I am saying that there is an explosion of solutions for every conceivable challenge, and the problem is that they are all islands-onto-themselves - there is no standard way for application to communicate with each other, and ZeoMQ could solve that. For example, let's take the "central-logging" use-case, let's say you've chosen Logstash - you have a server that collects log-information from many different other applications - there are too many varied ways in which that can happen, and every other application has a different one. Mostly, that is solved by either a centralized message-broker (say, RabbitMQ), or using Redis. Another example - a CI story (Continuous-Integration) : You have a process for automatically running your unit-tests, and in case any of them fail, it should generating an "issue" and submitting it so some issue-tracker (lets say Redmine). If all succeeds, it should commit the changes using a version-control (let's say Git), and push it to somewhere. Additionally, it may also create a task for code-review, in some ALM (Application-Life-cycle-Management) system, let's say Microsoft TFS for visual-studio (Team-Foundation-Server), or MyLyn for Eclipse. How many different applications have to talk to each other in this story?
That's the overall background. As for web2py: It already has a ticketing system built-in, but I can't use it to talk to the rest of my existing CI story. I want something that can talk to Mylyn, as I have Eclipse, so I use Redmine, as I don't want to write a Mylyn connector in Java - that's not my field... So now I need web2py to talk to Redmine... I also want my web2py-app's application-level custom logging mechanism, to not only be saved to it's database, but also submit to Logstash. I may be able to do that with Redis, but it would be great if I didn't have to... > Anyway, yes, it's cool, you don't worry about message delivery because > it's completely out of your control. That's the exact problem with it > though, message delivery is out of your control. You have no idea if a > message is delivered or not. You can 'queue' tons of messages, and ZeroMQ > won't tell you that those messages didn't get delivered. It's cool, but > it's not a silver bullet. Contrib may be a place for it though. > That is one of the common misconceptions. On the contrary - it is exactly thanks to ZeroMQ, that you have much MORE control over what is going on in your messaging architecture, NOT LESS. In sharp contrast to, say, RabbitMQ for AMQP, you are not locked into an implementation, or a strict protocol-spec - it is completely customizable. RabbitMQ simply implements the AMQP protocol-spec, so it MUST notify the senders about recipient's received message - it's a mandatory requirement in the QoS policy of the protocol. ZeroMQ CAN also do this, it is just NOT MANDATORY. The ability to submit to a recipient without it even being active, is a FEATURE, NOT a PROBLEM. It just means that a sending server may be set to have it's out-going sockets "queued", so whenever the target-recipient comes on-line, he starts receiving the messages in the out-going queue. When that happens, there is nothing preventing from the recipient from sending back replies for assuring the message was received - in fact, by default most typologies are set so that every message-received, is "echo"ed back to the sender, so it can cross-reference and make sure that the message goth through. Remember, both AMQP AND ZeroMQ are already being used in banks for transferring transactions, so the QoS is very reliable, if that is what you want - you just don't HAVE to use it, if you don't want to. -- --- 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.
