Sounds to me like you have a couple of real life situations you need solutions for. So the best thing to do is start coding. If you're unsure about how to tackle the web2py integration, I'm sure people will provide comments once you present your specific ideas or code drafts. If you start out in a form of a plugin, keeping in mind that it could be integrated in web2py one day, you IMHO can't go wrong.
Regards, Ales On Thursday, April 11, 2013 11:58:24 AM UTC+2, Arnon Marcus wrote: > > > 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.
