The Rabbit to CouchDB relay is a simple shovel (as Ben puts it), taking messages from queues and putting them into CouchDB.
It has a command channel by using an AMQP exchange. Through the command channel it can be told to listen or stop listening to queues.
The use case for Rabbiter is to store messages in feeds. Views on the CouchDB database can then compile things like a person's feed in order (e.g., for the "last ten messages" kind of view).
The aim is to bootstrap from as little information as possible. None would be good. But of course it needs to know three main things: from where to receive commands, where to put messages, and where to listen for messages.
In principle, one relay could listen to a number of AMQP servers and insert into a number of CouchDB databases (in a number of CouchDB instances). For the sake of simplicity, we'll restrict it to one AMQP host and one CouchDB instance.
CouchDB then seems like a natural places to put all the configuration, so all we really need to do is point the relay at a CouchDB host and database from which to get the rest of its configuration as a document. The configuration can be put there ahead of time, as a matter of deployment. Or it can be left to default, for development.
The configuration document looks like (with defaults):
{'amqp-host': localhost,
'amqp-port': 5672,
'command-exchange': 'amqp-relay-command',
'message-db': 'amqp-messages',
'listen': []
}
Design point: would it be better to have a separate document for the listen specs, or even a document per listen? That would better match the required granularity (e.g., we don't need to lock the whole configuration to add a listener)
Commands are JSON-RPC documents with named parameters.
Adds a listener. Will overwrite in the case of an existing listener with the id given.
Method name "add"
Parameters:
|
id |
the ID of the listener, for to refer to it later. Optional. |
|
queue |
an object with the arguments from queue.declare |
|
exchange |
a list of zero or more objects, each with the arguments to exchange.declare |
|
binding |
a list of zero or more objects, each with the arguments to queue.bind except the queue name (which is implicitly the name of the queue from above, either as supplied, or if empty, as returned by the broker) |
|
command |
(intended) something specifying how messages are inserted into couchdb (e.g., a template for the document) |