[rabbitmq-discuss] AMQP ruby client

[Aman Gupta]

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:
  amq.queue('test').peek{ |value|
    # value is is still in the queue
  }

  amq.queue('test').pop{ |value|
    # value no longer in the queue
  }

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.

  Aman

On Fri, Jul 18, 2008 at 3:45 AM, Jonathan Conway <jonathan at jaikoo.com>
wrote:

> Fantastic stuff! I can't wait to start using this:)
> 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.
>
> 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:).
>
> Cheers
>
> Jonathan
>
> --
> http://www.jaikoo.com
>
>
> On Fri, Jul 18, 2008 at 9:24 AM, Alexis Richardson <
> alexis.richardson at cohesiveft.com> wrote:
>
>> Aman
>>
>> Congrats on your Ruby API for RabbitMQ :-)
>>
>> On Fri, Jul 18, 2008 at 2:57 AM, Aman Gupta <rabbitmq at tmm1.net> wrote:
>> > I've just finished a simple high level api, and committed several
>> examples
>> > showing off direct, topic, fanout and rpc style messaging over rabbitmq:
>> >   http://github.com/tmm1/amqp/tree/master/examples/pingpong.rb
>> >   http://github.com/tmm1/amqp/tree/master/examples/clock.rb
>> >   http://github.com/tmm1/amqp/tree/master/examples/stocks.rb
>> >   http://github.com/tmm1/amqp/tree/master/examples/hashtable.rb
>>
>> Thanks so much for this, those examples are really useful.
>>
>>
>> > The API revolves around an MQ object, which corresponds 1:1 with an AMQP
>> > channel. An AMQP connection is created automatically by the MQ class (on
>> > demand), so you don't have to worry about connection, channel or
>> sessions.
>> > In the simplest case, MQ objects allow publishing to exchanges and
>> reading
>> > from queues:
>> >   amq = MQ.new
>> >   amq.queue('queue_name').subscribe{ |msg|
>> >     puts "i got a message: #{msg}"   # msg == "hello world"
>> >   end
>> >   amq.direct.publish('hello world', :key => 'queue_name')
>>
>> Cool.  This a great base API.
>>
>> So .. I guess what we are finding when talking about RabbitMQ with
>> folks from the Ruby and RoR community is that there are quite a few
>> different approaches to messaging.  In fact many people find messaging
>> to be unfamiliar and in need of explanation and use cases.
>>
>> For example:
>> http://nubyonrails.com/articles/about-this-blog-beanstalk-messaging-queue
>>
>> For some people, a cache / hashtable type approach, where everything
>> looks like a 'get' or a 'set' feels intuitive.  Others like
>> ActiveMessaging.  Do you have a view on whether higher level APIs, eg
>> defaulting to a subset of all behaviours, would be of interest to
>> people?
>>
>> And - generally - what do folks on the list think?
>>
>> Cheers,
>>
>> alexis
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20080718/75dadd00/attachment.htm