From ea66b6560bb40141281a35c97ed0a735f228cfb6 Mon Sep 17 00:00:00 2001 From: Andrew Godwin Date: Tue, 3 May 2016 18:43:15 -0700 Subject: [PATCH] Doc spelling corrections --- docs/concepts.rst | 2 +- docs/cross-compat.rst | 2 +- docs/deploying.rst | 4 ++-- docs/getting-started.rst | 2 +- docs/testing.rst | 4 ++-- 5 files changed, 7 insertions(+), 7 deletions(-) diff --git a/docs/concepts.rst b/docs/concepts.rst index 3fcb63f..a5b43b4 100644 --- a/docs/concepts.rst +++ b/docs/concepts.rst @@ -32,7 +32,7 @@ What is a channel? It is an *ordered*, *first-in first-out queue* with You can think of it as analogous to a task queue - messages are put onto the channel by *producers*, and then given to just one of the *consumers* -listening to that channnel. +listening to that channel. By *at-most-once* we say that either one consumer gets the message or nobody does (if the channel implementation crashes, let's say). The diff --git a/docs/cross-compat.rst b/docs/cross-compat.rst index f9b2f59..ab6541e 100644 --- a/docs/cross-compat.rst +++ b/docs/cross-compat.rst @@ -1,4 +1,4 @@ -Cross-Compatability +Cross-Compatibility =================== Channels is being released as both a third-party app for Django 1.8 and 1.9, diff --git a/docs/deploying.rst b/docs/deploying.rst index e5d16cc..974c135 100644 --- a/docs/deploying.rst +++ b/docs/deploying.rst @@ -86,7 +86,7 @@ the same workers as HTTP requests, there's a chance long-running tasks could block up all the workers and delay responding to HTTP requests). To manage this, it's possible to tell workers to either limit themselves to -just certain channel names or ignore sepcific channels using the +just certain channel names or ignore specific channels using the ``--only-channels`` and ``--exclude-channels`` options. Here's an example of configuring a worker to only serve HTTP and WebSocket requests:: @@ -166,7 +166,7 @@ rollouts to make sure workers on new code aren't experiencing high error rates. There's no need to restart the WSGI or WebSocket interface servers unless you've upgraded your version of Channels or changed any settings; none of your code is used by them, and all middleware and code that can -customise requests is run on the consumers. +customize requests is run on the consumers. You can even use different Python versions for the interface servers and the workers; the ASGI protocol that channel layers communicate over diff --git a/docs/getting-started.rst b/docs/getting-started.rst index b71dc35..8968377 100644 --- a/docs/getting-started.rst +++ b/docs/getting-started.rst @@ -182,7 +182,7 @@ of the time anyway. on 100% guaranteed delivery, which Channels won't give you, look at each failure case and program something to expect and handle it - be that retry logic, partial content handling, or just having something not work that one - time. HTTP requests are just as fallible, and most people's reponse to that + time. HTTP requests are just as fallible, and most people's response to that is a generic error page! .. _websocket-example: diff --git a/docs/testing.rst b/docs/testing.rst index 55476ba..d10a4c6 100644 --- a/docs/testing.rst +++ b/docs/testing.rst @@ -2,7 +2,7 @@ Testing Consumers ================= When you want to write unit tests for your new Channels consumers, you'll -realise that you can't use the standard Django test client to submit fake HTTP +realize that you can't use the standard Django test client to submit fake HTTP requests - instead, you'll need to submit fake Messages to your consumers, and inspect what Messages they send themselves. @@ -15,7 +15,7 @@ ChannelTestCase If your tests inherit from the ``channels.tests.ChannelTestCase`` base class, whenever you run tests your channel layer will be swapped out for a captive -in-memory layer, meaning you don't need an exernal server running to run tests. +in-memory layer, meaning you don't need an external server running to run tests. Moreover, you can inject messages onto this layer and inspect ones sent to it to help test your consumers.