<div>
As a follow up just see today's hacker news top article: http://news.ycombinator.com/item?id=3899080
</div><div><br></div><div>Yes, that the article is top on HN might not mean much… but at least the idea suggested there is popular, ie: people might want that.</div><div><br></div><div>-Alvaro</div>
<div><div><br></div><div>-- </div><div>Sent with <a href="http://www.sparrowmailapp.com/?sig">Sparrow</a></div><div><br></div></div>
<p style="color: #A0A0A8;">On Wednesday, April 18, 2012 at 1:42 PM, Alexis Richardson wrote:</p>
<blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;">
<span><div><div><div>I'm in favour of anything that makes it easier to get started.</div><div><br></div><div>I am continually surprised to hear things like "rabbit has queues but</div><div>not pubsub" as well as "rabbit is good for pubsub but not queues".</div><div>Not to forget "rabbit does not do persistence" as well as "rabbit is</div><div>best for persistence" and of course "rabbit uses mnesia for message</div><div>persistence" when it doesn't. In addition all kinds of FUD gets slung</div><div>about.</div><div><br></div><div>The Redis community has been great at innovating from the bottom</div><div>upwards, to deliver simplicity. This is immediately visible when you</div><div>look at the slew of MQ-alike layers that people have created. These</div><div>tend to focus on the core functions of pubsub, queue, and sometimes</div><div>1-1 and/or RPC; while ignoring eg flow control, paging, and other</div><div>features. Some layer a work queue system on top of Redis, like</div><div>Celery. Resque is a good example of that.</div><div><br></div><div>Here are more examples:</div><div><br></div><div><a href="http://thechangelog.com/post/6791886560/thoonk-py-persistent-and-fast-push-feeds-queues-and-jobs">http://thechangelog.com/post/6791886560/thoonk-py-persistent-and-fast-push-feeds-queues-and-jobs</a></div><div>("a project that takes a unified approach to feeds, jobs, and queues,</div><div>all with a Redis backend." and looks a lot like rabbit)</div><div><br></div><div><a href="https://github.com/djhworld/redis-mq">https://github.com/djhworld/redis-mq</a> ("I felt tools like the</div><div>excellent RabbitMQ were too complex for small projects like the ones I</div><div>tend to make.")</div><div><br></div><div><a href="https://github.com/ServiceStack/ServiceStack/wiki/Messaging-and-redis">https://github.com/ServiceStack/ServiceStack/wiki/Messaging-and-redis</a></div><div>(WCF for hipsters)</div><div><br></div><div><a href="http://restmq.com">http://restmq.com</a>/ ("There are HTTP clients for pratically all</div><div>languages. That's all that it takes to use RestMQ within your</div><div>application. No special protocols or strategies, just dynamically</div><div>created queues.")</div><div><br></div><div><a href="http://lumberjaph.net/perl/2010/04/14/presque-a-redis-tatsumaki-based-message-queue.html">http://lumberjaph.net/perl/2010/04/14/presque-a-redis-tatsumaki-based-message-queue.html</a></div><div>("a small message queue service build on top of redis and Tatsumaki.</div><div>It’s heavily inspired by RestMQ and resque.")</div><div><br></div><div><a href="http://flask.pocoo.org/snippets/73/">http://flask.pocoo.org/snippets/73/</a> ("if you just want a very basic</div><div>queue functionality to get started")</div><div><br></div><div><a href="https://github.com/josiahcarlson/rpqueue">https://github.com/josiahcarlson/rpqueue</a> (priority queue)</div><div><br></div><div>All of these projects are motivated by ease of use and a simple API.</div><div>Let's make Rabbit easier to use.</div><div><br></div><div>alexis</div><div><br></div><div><br></div><div><br></div><div><br></div><div>On Wed, Apr 11, 2012 at 5:36 PM, Jason J. W. Williams</div><div><<a href="mailto:jasonjwwilliams@gmail.com">jasonjwwilliams@gmail.com</a>> wrote:</div><blockquote type="cite"><div><div>I think this is a great idea. It makes it easier to on onboard those who initially need a simple message queue and end up using Redis. Whatever message queue tech people start with for their first quick and dirty needs they tend to stick with. So I think this is a great idea for getting folks converted to Rabbit early.</div><div><br></div><div>Yes functionally anonymous queues function the same way, but conceptually they break the idea exchanges are where you publish messages since you supply the "empty" exchange.</div><div><br></div><div>Whether its a new exchange type or a change to the library API for anonymous queues, I like the direction Alvaro's going for folks getting their feet wet.</div><div><br></div><div>-J</div><div><br></div><div>Sent via iPhone</div><div><br></div><div>Is your email Premiere?</div><div><br></div><div>On Apr 11, 2012, at 7:13, Alvaro Videla <<a href="mailto:videlalvaro@gmail.com">videlalvaro@gmail.com</a>> wrote:</div><div><br></div><blockquote type="cite"><div><div>Hi,</div><div><br></div><div>I've been thinking on creating a new exchange type whose goal will be to simplify the ways messages are routed to queues.</div><div><br></div><div>So now for example to publish a message to a queue I need to do something like:</div><div><br></div><div>$ch->exchange_declare('foobar', 'direct');</div><div>$ch->queue_declare('foobar');</div><div>$ch->queue_bind('foobar', 'foobar');</div><div>$ch->basic_publish($msg, 'foobar');</div><div><br></div><div>I want to be able to do this:</div><div><br></div><div>$ch->exchange_declare('foobar', 'new-exchange-type');</div><div>$ch->basic_publish($msg, 'foobar');</div><div><br></div><div>So that means that by declaring a "foobar" exchange with the new type I will bind a new queue to that exchange during exchange creation on the broker side.</div><div><br></div><div>The queue will have similar durability properties as the exchange.</div><div><br></div><div>The exchange won't accept binding requests, so 1 exchange of that type will only have 1 queue bound to it.</div><div><br></div><div>The idea is also to not perform any query while searching for a queue where to route messages, so routing speed *should* be a bit faster than a normal direct exchange.</div><div><br></div><div>The exchange should act basically as a direct exchange.</div><div><br></div><div>Then as a user of RabbitMQ that just want to have a queue server for delayed jobs this is the most basic setup I think you can have.</div><div><br></div><div>BTW, I know you can publish messages to the anon exchange by using the queue name as routing key, but this requires that particular knowledge of AMQP.</div><div><br></div><div>What do you guys think?</div><div><br></div><div>-Alvaro</div><div>_______________________________________________</div><div>rabbitmq-discuss mailing list</div><div><a href="mailto:rabbitmq-discuss@lists.rabbitmq.com">rabbitmq-discuss@lists.rabbitmq.com</a></div><div><a href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss">https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a></div></div></blockquote><div>_______________________________________________</div><div>rabbitmq-discuss mailing list</div><div><a href="mailto:rabbitmq-discuss@lists.rabbitmq.com">rabbitmq-discuss@lists.rabbitmq.com</a></div><div><a href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss">https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a></div></div></blockquote></div></div></span>
</blockquote>
<div>
<br>
</div>