<div dir="ltr">I plan on adding #peek and #pop to the queues, in addition to the #subscribe already in there. However, like subscribe, these will be asynchronous, requiring a block to process the return value:<div><br></div>
<div> amq.queue('test').peek{ |value|</div><div> # value is is still in the queue</div><div> }</div><div><br></div><div> amq.queue('test').pop{ |value|</div><div> # value no longer in the queue</div>
<div> }</div><div><br></div><div>I have a few other things on my todo list, the most important of which are apis to remove bindings/queues and to ack/reject messages.</div><div><br></div><div> Aman<br><br><div class="gmail_quote">
On Fri, Jul 18, 2008 at 3:45 AM, Jonathan Conway <<a href="mailto:jonathan@jaikoo.com">jonathan@jaikoo.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div dir="ltr">Fantastic stuff! I can't wait to start using this:)<div><br></div><div>With regards to Alexis's question, everyone loves the simplest solution which is how things should be. I only think the get/set style became popular as it gave familiarity to an existing API which in this case was memcache and not because of it's technical merits, though I could be wrong.</div>
<div><br></div><div>But personally I think the pub/sub model is better and dare I use the word more 'scalable' (I know it's a badly used word these days). Having an API that just exposes this and not other behaviors would be the simplest and best way forward in my lowly opinion. One true path:).</div>
<div><br></div><div>Cheers</div><div><br></div><div>Jonathan<br><br></div><div>-- <br><div class="gmail_quote"><a href="http://www.jaikoo.com" target="_blank">http://www.jaikoo.com</a></div><div><div></div><div class="Wj3C7c">
<div class="gmail_quote"><br></div><div class="gmail_quote">
<br></div><div class="gmail_quote">On Fri, Jul 18, 2008 at 9:24 AM, Alexis Richardson <<a href="mailto:alexis.richardson@cohesiveft.com" target="_blank">alexis.richardson@cohesiveft.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Aman<br>
<br>
Congrats on your Ruby API for RabbitMQ :-)<br>
<br>
On Fri, Jul 18, 2008 at 2:57 AM, Aman Gupta <<a href="mailto:rabbitmq@tmm1.net" target="_blank">rabbitmq@tmm1.net</a>> wrote:<br>
> I've just finished a simple high level api, and committed several examples<br>
> showing off direct, topic, fanout and rpc style messaging over rabbitmq:<br>
> <a href="http://github.com/tmm1/amqp/tree/master/examples/pingpong.rb" target="_blank">http://github.com/tmm1/amqp/tree/master/examples/pingpong.rb</a><br>
> <a href="http://github.com/tmm1/amqp/tree/master/examples/clock.rb" target="_blank">http://github.com/tmm1/amqp/tree/master/examples/clock.rb</a><br>
> <a href="http://github.com/tmm1/amqp/tree/master/examples/stocks.rb" target="_blank">http://github.com/tmm1/amqp/tree/master/examples/stocks.rb</a><br>
> <a href="http://github.com/tmm1/amqp/tree/master/examples/hashtable.rb" target="_blank">http://github.com/tmm1/amqp/tree/master/examples/hashtable.rb</a><br>
<br>
Thanks so much for this, those examples are really useful.<br>
<br>
<br>
> The API revolves around an MQ object, which corresponds 1:1 with an AMQP<br>
> channel. An AMQP connection is created automatically by the MQ class (on<br>
> demand), so you don't have to worry about connection, channel or sessions.<br>
> In the simplest case, MQ objects allow publishing to exchanges and reading<br>
> from queues:<br>
> amq = MQ.new<br>
> amq.queue('queue_name').subscribe{ |msg|<br>
> puts "i got a message: #{msg}" # msg == "hello world"<br>
> end<br>
> amq.direct.publish('hello world', :key => 'queue_name')<br>
<br>
Cool. This a great base API.<br>
<br>
So .. I guess what we are finding when talking about RabbitMQ with<br>
folks from the Ruby and RoR community is that there are quite a few<br>
different approaches to messaging. In fact many people find messaging<br>
to be unfamiliar and in need of explanation and use cases.<br>
<br>
For example: <a href="http://nubyonrails.com/articles/about-this-blog-beanstalk-messaging-queue" target="_blank">http://nubyonrails.com/articles/about-this-blog-beanstalk-messaging-queue</a><br>
<br>
For some people, a cache / hashtable type approach, where everything<br>
looks like a 'get' or a 'set' feels intuitive. Others like<br>
ActiveMessaging. Do you have a view on whether higher level APIs, eg<br>
defaulting to a subset of all behaviours, would be of interest to<br>
people?<br>
<br>
And - generally - what do folks on the list think?<br>
<br>
Cheers,<br>
<br>
alexis</blockquote></div><br clear="all"><br><br></div></div></div></div>
</blockquote></div><br></div></div>