Comments on: To AMQP or to XMPP, that is the question http://www.opensourcery.co.za/2009/04/19/to-amqp-or-to-xmpp-that-is-the-question/ Wizardry through open source Mon, 02 May 2011 17:05:16 +0000 hourly 1 http://wordpress.org/?v=3.1.2 By: Advanced Messaging & Routing with AMQP « Yet another wordpress blog http://www.opensourcery.co.za/2009/04/19/to-amqp-or-to-xmpp-that-is-the-question/comment-page-1/#comment-841 Advanced Messaging & Routing with AMQP « Yet another wordpress blog Mon, 02 May 2011 17:05:16 +0000 http://www.opensourcery.co.za/?p=173#comment-841 [...] AMQP vs XMPP debate has been raging for years now. On the surface they both look identical, but in reality there are a number of important [...] [...] AMQP vs XMPP debate has been raging for years now. On the surface they both look identical, but in reality there are a number of important [...]

]]> By: Advanced Messaging & Routing with AMQP http://www.opensourcery.co.za/2009/04/19/to-amqp-or-to-xmpp-that-is-the-question/comment-page-1/#comment-819 Advanced Messaging & Routing with AMQP Mon, 09 Aug 2010 15:19:03 +0000 http://www.opensourcery.co.za/?p=173#comment-819 [...] AMQP vs XMPP debate has been raging for years now. On the surface they both look identical, but in reality there are a number of important [...] [...] AMQP vs XMPP debate has been raging for years now. On the surface they both look identical, but in reality there are a number of important [...]

]]> By: prashanth http://www.opensourcery.co.za/2009/04/19/to-amqp-or-to-xmpp-that-is-the-question/comment-page-1/#comment-811 prashanth Fri, 12 Mar 2010 07:12:20 +0000 http://www.opensourcery.co.za/?p=173#comment-811 Wouldn't it be better to use AMQP and XMPP for different purpose? Use AMQP for message queuing for background tasks and XMPP for real time publishing to webclients i.e instead of polling use BOSH along with XMPP? Wouldn’t it be better to use AMQP and XMPP for different purpose?
Use AMQP for message queuing for background tasks and XMPP for real time publishing to webclients i.e instead of polling use BOSH along with XMPP?

]]> By: Kenneth Kalmer http://www.opensourcery.co.za/2009/04/19/to-amqp-or-to-xmpp-that-is-the-question/comment-page-1/#comment-766 Kenneth Kalmer Sun, 13 Dec 2009 20:06:18 +0000 http://www.opensourcery.co.za/?p=173#comment-766 Love affair has persisted. AMQP is part of my everyday work and has really nestled itself quite deeply into my toolbox. I still have my eyes on XMPP though, libraries like <a href="http://github.com/sprsquish/blather" rel="nofollow">Blather</a> makes XMPP a dream to work with. But like the post stresses, best tool for the job. Love affair has persisted. AMQP is part of my everyday work and has really nestled itself quite deeply into my toolbox. I still have my eyes on XMPP though, libraries like Blather makes XMPP a dream to work with. But like the post stresses, best tool for the job.

]]> By: Rj http://www.opensourcery.co.za/2009/04/19/to-amqp-or-to-xmpp-that-is-the-question/comment-page-1/#comment-765 Rj Fri, 06 Nov 2009 11:40:55 +0000 http://www.opensourcery.co.za/?p=173#comment-765 So, how have you gone with AMQP? Has your love affair persisted or are you back with XMPP? So, how have you gone with AMQP? Has your love affair persisted or are you back with XMPP?

]]> By: Driving Business Processes in Ruby | Open Sourcery http://www.opensourcery.co.za/2009/04/19/to-amqp-or-to-xmpp-that-is-the-question/comment-page-1/#comment-450 Driving Business Processes in Ruby | Open Sourcery Mon, 06 Jul 2009 07:45:23 +0000 http://www.opensourcery.co.za/?p=173#comment-450 [...] tough, and the impact of the next decisions are even bigger. I recently tackled the issue of choosing between AMQP and XMPP (and I’m honestly still on the bench, even when I’m using both in production), and [...] [...] tough, and the impact of the next decisions are even bigger. I recently tackled the issue of choosing between AMQP and XMPP (and I’m honestly still on the bench, even when I’m using both in production), and [...]

]]> By: Stephen Paul Weber http://www.opensourcery.co.za/2009/04/19/to-amqp-or-to-xmpp-that-is-the-question/comment-page-1/#comment-340 Stephen Paul Weber Tue, 05 May 2009 18:55:57 +0000 http://www.opensourcery.co.za/?p=173#comment-340 I think stpeter's point was that you don't even need a concept of friend requests in XMPP. You should be able to safely ignore those packets, or just in general not use them. XMPP is a stateful messaging protocol that happens to be really good at IM... it is not IM specific (although some XEP's are) I think stpeter’s point was that you don’t even need a concept of friend requests in XMPP. You should be able to safely ignore those packets, or just in general not use them.

XMPP is a stateful messaging protocol that happens to be really good at IM… it is not IM specific (although some XEP’s are)

]]> By: Kyle Schaffrick http://www.opensourcery.co.za/2009/04/19/to-amqp-or-to-xmpp-that-is-the-question/comment-page-1/#comment-323 Kyle Schaffrick Fri, 01 May 2009 18:22:34 +0000 http://www.opensourcery.co.za/?p=173#comment-323 @Scott I think the secret sauce AMQP has that SMTP/NNTP lack is that the routing is configurable "on the wire," in the sense that clients declare what exchanges, queues, and bindings they intend to use and how they relate to each other, as part of the ordinary course of using the broker's services. These meta-level features are defined by the AMQP spec, both in protocol and semantics. On the other hand, a message queueing system implemented in SMTP/NNTP would have to A) define these meta-level features in an ad-hoc way and then implement them itself, separately from or as an extension to the actual broker/MTA, or B) give up this dynamic configurability, in which case the broker would have to know a priori (via configuration) what the distribution patterns should be. The fact that (for instance) RabbitMQ had essentially *no* static configuration files to edit (in stark contrast with most MTAs, to be sure) baffled me for a time until I realized that it worked this way. After some consideration, I believe it is one of the great strengths of AMQP's approach. @Scott I think the secret sauce AMQP has that SMTP/NNTP lack is that the routing is configurable “on the wire,” in the sense that clients declare what exchanges, queues, and bindings they intend to use and how they relate to each other, as part of the ordinary course of using the broker’s services. These meta-level features are defined by the AMQP spec, both in protocol and semantics.

On the other hand, a message queueing system implemented in SMTP/NNTP would have to A) define these meta-level features in an ad-hoc way and then implement them itself, separately from or as an extension to the actual broker/MTA, or B) give up this dynamic configurability, in which case the broker would have to know a priori (via configuration) what the distribution patterns should be.

The fact that (for instance) RabbitMQ had essentially *no* static configuration files to edit (in stark contrast with most MTAs, to be sure) baffled me for a time until I realized that it worked this way. After some consideration, I believe it is one of the great strengths of AMQP’s approach.

]]> By: jay http://www.opensourcery.co.za/2009/04/19/to-amqp-or-to-xmpp-that-is-the-question/comment-page-1/#comment-302 jay Mon, 27 Apr 2009 23:23:53 +0000 http://www.opensourcery.co.za/?p=173#comment-302 Good thoughts, and good luck. I read this article yesterday that maybe helpful with AMQP. It's python but I don't think that should stall anyone; http://blogs.digitar.com/jjww/2009/01/rabbits-and-warrens/comment-page-19/#comment-2376 Good thoughts, and good luck. I read this article yesterday that maybe helpful with AMQP. It’s python but I don’t think that should stall anyone;

http://blogs.digitar.com/jjww/2009/01/rabbits-and-warrens/comment-page-19/#comment-2376

]]> By: Scott Stults http://www.opensourcery.co.za/2009/04/19/to-amqp-or-to-xmpp-that-is-the-question/comment-page-1/#comment-293 Scott Stults Sat, 25 Apr 2009 13:14:28 +0000 http://www.opensourcery.co.za/?p=173#comment-293 Whenever I see a new message queuing system, I always wonder why nobody chooses SMTP and NNTP. Those protocols have been around forever. They have solid, scalable implementations, support guaranteed delivery, and together support one-to-one and one-to-many transmission. The writers of SOAP realized this, but I've yet to see anyone use SMTP to deliver SOAP calls (and nobody wants to do SOAP nowadays anyway.) That said, I agree that ruote and XMPP are excellent, and I look forward to seeing how your AMQP implementation works out. Whenever I see a new message queuing system, I always wonder why nobody chooses SMTP and NNTP. Those protocols have been around forever. They have solid, scalable implementations, support guaranteed delivery, and together support one-to-one and one-to-many transmission. The writers of SOAP realized this, but I’ve yet to see anyone use SMTP to deliver SOAP calls (and nobody wants to do SOAP nowadays anyway.)

That said, I agree that ruote and XMPP are excellent, and I look forward to seeing how your AMQP implementation works out.

]]>