[rabbitmq-discuss] [New project] amqp-utils, CLI utilities for AMQP queues

Sat Feb 7 13:49:49 GMT 2009

Jason,

Have you looked at how Tony's JSON-RPC over AMQP over HTTP works?  The
code is in the HTTP libs in the repo, IIRC.

alexis

On Fri, Feb 6, 2009 at 6:55 PM, Jason J. W. Williams
<jasonjwwilliams at gmail.com> wrote:
> Personally, I'd like to see it exposed over AMQP using queues with
> chosen reserved names. Exposing it over JSON would be great, but I
> think if we're already using AMQP to access it, it should be pretty
> easy to build a web GUI that uses AMQP to get the answers.
>
> -J
>
> On Fri, Feb 6, 2009 at 8:46 AM, Alexis Richardson
> <alexis.richardson at cohesiveft.com> wrote:
>> Valentino,
>>
>> Thanks, that is a very useful contribution.  I'll ask Tony how hard it
>> would be to expose this using his JSON stuff.
>>
>> alexis
>>
>>
>>
>>
>> On Thu, Feb 5, 2009 at 9:55 AM, Valentino Volonghi <dialtone at gmail.com> wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>>
>>> On Feb 5, 2009, at 1:35 AM, Alexis Richardson wrote:
>>>
>>>> Thanks for the feedback on this.
>>>>
>>>> As Valentino and Al point out, keeping things compact is important,
>>>> and not all users are running or want to run a web framework with
>>>> RabbitMQ.  Though of course some will.
>>>>
>>>> So one option here is to use the built-in HTTP capability rather than
>>>> a web framework.  For example, to provide an interface to rabbitmqctl
>>>> that lets people use a browser to keep an eye on the broker.
>>>>
>>>> On the other hand people may prefer programmatic management.
>>>
>>>
>>> I'm pretty sure that with an HTTP server built-in you can do anything
>>> to rabbitmq, even writing consumers in javascript :).
>>>
>>> More seriously:
>>> An HTTP server that exposes some kind of simple REST API that
>>> can be queries also from javascript would mean that even a static
>>> page (hardly a match for a built-in http server) could be served
>>> efficiently and act as a monitoring screen.
>>>
>>> As for the REST API I'm thinking along the lines of:
>>>
>>> /stats/ <- general stats and list of exchanges
>>> /stats/<EXCHANGE>/ <- list of queues under exchange
>>> /stats/<EXCHANGE>/<QUEUE>/ <- queue stats
>>> /stats/users/
>>> /stats/consumers/
>>> /stats/acls/
>>> ...
>>>
>>> simple http-auth is more than enough if you really want to make
>>> this secure and could use the same users credentials that rabbitmq
>>> stores for the rest of the system. And the response format for each
>>> request would simply be JSON, then a single html page can be
>>> used to show all the stats that one might need. This has no memory
>>> overhead because everything is done on the client side and can be
>>> freely extended by simply changing javascript without the need to
>>> deploy a new web server somewhere (etc etc).
>>>
>>> Then by quering (polling at the beginning, comet when there's more
>>> time to develop something like this) a url multiple times one can build
>>> a chart of the stats (and if polling the built-in http server doesn't even
>>> need to know that it is happening).
>>>
>>> - --
>>> Valentino Volonghi aka Dialtone
>>> Now running MacOS X 10.5
>>> Home Page: http://www.twisted.it
>>> http://www.adroll.com
>>>
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v1.4.9 (Darwin)
>>>
>>> iEYEARECAAYFAkmKt4sACgkQ9Llz28widGW65ACgtJTQCgE7ZYMLTFkuALRxSM+O
>>> pzwAnRlrN8uI6BS7vTEHKgOLFOzj1Lqd
>>> =7ifr
>>> -----END PGP SIGNATURE-----
>>>
>>
>> _______________________________________________
>> rabbitmq-discuss mailing list
>> rabbitmq-discuss at lists.rabbitmq.com
>> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>>
>