Change Details

**Userland view** ``` $ notifications [00:04] <tasacora> Something happened. https://app.domain.tld/somewhere. [00:05] <lorem> Something happened. https://app.domain.tld/somewhereaboutlorem. [00:07] <tasacora> Something else happened. https://app.domain.tld/somewhereelse. ``` As we use a AMQP exchange, I'm going a flag to offer to filter by routing key: ``` $ notifications --routing-key "nasqueron.tasacora.#" [00:04] <tasacora> Something happened. https://app.domain.tld/somewhere. [00:07] <tasacora> Something else happened. https://app.domain.tld/somewhereelse. ``` **Application lifecycle** At startup, the client connects to the broker, creates a temporary queue bound to the ''notifications'' exchange and dedicated for the client, to get messages. When the broker sends a message to the client, we parse JSON and print it. The broker will take care to delete the temporary queue. **Plans about security** The application will connect directly to the RabbitMQ server. We'll store credentials by machine in `/usr/local/etc/notifications.conf` or `/etc/notifications.conf`. There is currently no plan to implement ACL for notifications, as notifications are public events you can get on our IRC channels or directly at the source.

**Userland view** ``` $ notifications [00:04] <tasacora> Something happened. https://app.domain.tld/somewhere. [00:05] <lorem> Something happened. https://app.domain.tld/somewhereaboutlorem. [00:07] <tasacora> Something else happened. https://app.domain.tld/somewhereelse. ``` As we use a AMQP exchange, I'm going a flag to offer to filter by routing key: ``` $ notifications --routing-key "nasqueron.tasacora.#" [00:04] <tasacora> Something happened. https://app.domain.tld/somewhere. [00:07] <tasacora> Something else happened. https://app.domain.tld/somewhereelse. ``` **Application lifecycle** At startup, the client connects to the broker, creates a temporary queue bound to the ''notifications'' exchange and dedicated for the client, to get messages. When the broker sends a message to the client, we parse JSON and print it. The broker will take care to delete the temporary queue. **Plans about security** The application will connect directly to the RabbitMQ server. We'll store credentials by machine in `/usr/local/etc/notifications.conf` or `/etc/notifications.conf`, with read-only access to public dev data on the broker. There is currently no plan to implement ACL for notifications, as notifications are public events you can get on our IRC channels or directly at the source.

**Userland view** ``` $ notifications [00:04] <tasacora> Something happened. https://app.domain.tld/somewhere. [00:05] <lorem> Something happened. https://app.domain.tld/somewhereaboutlorem. [00:07] <tasacora> Something else happened. https://app.domain.tld/somewhereelse. ``` As we use a AMQP exchange, I'm going a flag to offer to filter by routing key: ``` $ notifications --routing-key "nasqueron.tasacora.#" [00:04] <tasacora> Something happened. https://app.domain.tld/somewhere. [00:07] <tasacora> Something else happened. https://app.domain.tld/somewhereelse. ``` **Application lifecycle** At startup, the client connects to the broker, creates a temporary queue bound to the ''notifications'' exchange and dedicated for the client, to get messages. When the broker sends a message to the client, we parse JSON and print it. The broker will take care to delete the temporary queue. **Plans about security** The application will connect directly to the RabbitMQ server. We'll store credentials by machine in `/usr/local/etc/notifications.conf` or `/etc/notifications.conf`, with read-only access to public dev data on the broker. There is currently no plan to implement ACL for notifications, as notifications are public events you can get on our IRC channels or directly at the source.