--- a/pyforge/docs/guides/message_bus.rst
+++ b/pyforge/docs/guides/message_bus.rst
@@ -6,14 +6,14 @@
two kinds of event listeners, *auditors* and *reactors*.
.. image:: ../_static/images/amqp.png
- :alt: App Plugins
+ :alt: App Tools
Glossary
----------------------------------
Before we get into the details perhaps a few definitions are in order:
-* **app** -- plugin for pyforge such as the tracker, scm, or wiki apps
+* **app** -- tool for pyforge such as the tracker, scm, or wiki apps
* **message event** -- any incoming message that's added to one of the amqp
queues
* **auditor** -- callable defined in a app that gets called on messages
@@ -26,7 +26,7 @@
* **reactor_exchange** -- durable queue for messages to reactor_queues
* **reactor_listener** -- *should not* put things back on the queue and
particularly not on the *same* queue, because that can cause infinite loops.
-* **app_queue** -- queue defined by an app plugin, has a single queue instance
+* **app_queue** -- queue defined by an app tool, has a single queue instance
for the system.
* **app_listeners** -- consumers for app_queues, must route appropriately to
project/subproject/app instance based on message contents, and call all
@@ -59,7 +59,7 @@
so you don't have to worry about any of that. The way it works is basically
to :
-* Iterate over each plugin P installed on the system and
+* Iterate over each tool P installed on the system and
* For each (pattern, callback) pair (p,c) in P:
* Start a worker process which will construct one consumer for a
new queue and register for the routing pattern p and the callback
@@ -75,14 +75,14 @@
Routing keys refer to the _topic_ of a message, not necessarily to its
_destination_. In this way, we decouple the producers and consumers
of messages. A routing key will generally have the form _source.topic_.
-For instance, a message may be generated by the scm plugin with the routing
+For instance, a message may be generated by the scm tool with the routing
key `scm.commit`. The message body would identify the project and particular
-SCM instance that _generated_ the message. The tracker plugin would then
+SCM instance that _generated_ the message. The tracker tool would then
have a listener on the `scm.#` routing pattern and would be invoked on
each SCM commit.
Note that in the case of email messages, the email address does _not_
- directly map to the routing key; the particular project/plugin that
+ directly map to the routing key; the particular project/tool that
is the destination of the email message is encoded into the message
body itself.
@@ -90,20 +90,20 @@
----------------------------------------------------------------
We will instantiate two AMQP exchanges, 'audit' and 'react'.
-Each plugin may register consumers on these exchanges.
+Each tool may register consumers on these exchanges.
Auditing
----------------------------------------------------------------
The audit exchange is typically used to request a particular
-plugin instance in a particular project to perform some action
+tool instance in a particular project to perform some action
(change the state of a ticket, index an object in SOLR, add a
comment to a wiki page or ticket, etc.) To register a consumer
on the auditor exchange, decorate a method in the application
class with the @audit decorator, specifying which routing
keys you are interested in (these decorators can be stacked).
For instance, to audit messages destined for the hello_forge
-plugin, you might write:
+tool, you might write:
::
@@ -114,16 +114,16 @@
When a message is received on the 'audit' exchange with the
'hello_forge.comment' routing key, the worker process will inspect the message
for _project_id_ and _mount_point_ fields and use these to populate the pylons
-context object 'c' with the current project and plugin application instance.
+context object 'c' with the current project and tool application instance.
The auditor method is then called with the application instance and the
routing key and payload from the message.
Reacting
----------------------------------------------------------------
-The react exchange is typically used to notify all the interested plugins in
-a project of changes in a particular plugin. For instance, when a commit is
-made to the SCM plugin, a notification message would be sent to the 'react'
+The react exchange is typically used to notify all the interested tools in
+a project of changes in a particular tool. For instance, when a commit is
+made to the SCM tool, a notification message would be sent to the 'react'
exchange to allow, for instance, a ticket noted in the commit message to be
linked to the commit object. To register a consumer for the reactor exchange,
decorate a method in the application class with the @react decorator,
@@ -140,7 +140,7 @@
When a message is received on the `react` exchange with the `wiki.comment`
routing key, the worker process will inspect the message for the _project_id_
field and use this to populate the pylons context object with the current
-project. It will then cycle through _all_instances_ of the plugin for the
+project. It will then cycle through _all_instances_ of the tool for the
given project, setting the `c.app` context and invoking the reactor
method with that instance, the routing key, and the payload from the
message. This allows each instance to decide what action to take in
@@ -161,7 +161,7 @@
In order to configure the queues, we have written a paster command
`reactor_setup`. This command will tear down any existing `audit` and `react`
exchanges and re-create them. It then creates one queue for each consumer
-method defined in all installed plugins and binds these queues appropriately
+method defined in all installed tools and binds these queues appropriately
to their exchanges. To actually run the reactor workers, we have written a
paster command `reactor` which creates a worker process for each queue.