Router decoupling and HTTP message processing

ewheeler edited this page Sep 27, 2011 · 16 revisions

This is a proposal to decouple/split up the RapidSMS route process in several key places and begin processing all SMSes in normal HTTP requests. It also includes making it possible to swap the Router class that RapidSMS uses via a setting in the settings file. It is still under construction so feel free to add additional resources or clarifications as you see fit. Any major changes should be discussed on the mailing list before being made.

Related Discussion

The following threads on the mailing contain some of the related discussion (feel free to add any not shown below). The most recent thread appears first and contains the most up-to-date discussion of the issues:

Related Code


  • The route process as it currently stands is complicated; it includes a number of threads and the ways in which they interact is not always intuitive
  • If the route process dies unexpectedly, all backends (and hence message processing) are brought offline
  • Automated testing is difficult and inefficient, because the router (and all its threads) needs to be started/stopped for each test


  • Separate the grunt work of each backend into its own process and call it a gateway. Kannel and pygsm-gateway are examples of gateway implementations
  • Gateways communicate to RapidSMS via HTTP; e.g., the gateway process polls for messages and posts them to the configured Django URL for that gateway’s backend
  • Maintain official gateways in separate code repositories, but ship them with RapidSMS
  • Each backend is implemented as a Django app with one or more URLs; the corresponding view extracts the incoming message from the HTTP request and passes it to the router for handling
  • Backend views will be implemented using Django 1.3’s generic views
  • Each gateway will manifest its own URL that handles outgoing messages and queues them up for delivery to the modem (or whatever)
  • The router class will be configurable from the settings file, so it may be swapped out with a new implementation if desired.
  • RapidSMS will ship with several router implementations, including a simple blocking class (the default for development and testing), one that uses celery to queue incoming and/or outgoing messages, and one that uses the database and threads to queue incoming and outgoing messages.
  • Test cases include a method to easily send messages to a test backend, as well as continue to support scripted tests


  • What to do with all the backends in rapidsms.backends (e.g., the email backend)?
  • Can any of the backends currently in core be eliminated during the refactor?