From eafb3c728dadd43514c155d294751ed2c915a3b4 Mon Sep 17 00:00:00 2001 From: Martin Pajuste Date: Sat, 12 Dec 2015 00:18:57 +0200 Subject: [PATCH] Fix some typos --- docs/concepts.rst | 2 +- docs/getting-started.rst | 6 +++--- docs/installation.rst | 4 ++-- docs/message-standards.rst | 2 +- docs/releases/0.8.rst | 2 +- docs/scaling.rst | 2 +- 6 files changed, 9 insertions(+), 9 deletions(-) diff --git a/docs/concepts.rst b/docs/concepts.rst index 1b3bc46..2b90fcf 100644 --- a/docs/concepts.rst +++ b/docs/concepts.rst @@ -28,7 +28,7 @@ The core of Channels is, unsurprisingly, a datastructure called a *channel*. What is a channel? It is an *ordered*, *first-in first-out queue* with *message expiry* and *at-most-once delivery* to *only one listener at a time*. -You can think of it as analagous to a task queue - messages are put onto +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. diff --git a/docs/getting-started.rst b/docs/getting-started.rst index 283cdcf..f7a0b7e 100644 --- a/docs/getting-started.rst +++ b/docs/getting-started.rst @@ -244,7 +244,7 @@ connection, as part of the query string (e.g. ``wss://host/websocket?room=abc``) The ``reply_channel`` attribute you've seen before is our unique pointer to the open WebSocket - because it varies between different clients, it's how we can -keep track of "who" a message is from. Remember, Channels is network-trasparent +keep track of "who" a message is from. Remember, Channels is network-transparent and can run on multiple workers, so you can't just store things locally in global variables or similar. @@ -384,7 +384,7 @@ Django session ID as part of the URL, like this:: You can get the current session key in a template with ``{{ request.session.session_key }}``. Note that Channels can't work with signed cookie sessions - since only HTTP -responses can set cookies, it needs a backend it can write to to separately to +responses can set cookies, it needs a backend it can write to to separately store state. @@ -484,7 +484,7 @@ whereas you'd naturally expect ``receive`` to run after ``connect``. But, of course, Channels has a solution - the ``linearize`` decorator. Any handler decorated with this will use locking to ensure it does not run at the same time as any other view with ``linearize`` **on messages with the same reply channel**. -That means your site will happily mutitask with lots of different people's messages, +That means your site will happily multitask with lots of different people's messages, but if two happen to try to run at the same time for the same client, they'll be deconflicted. diff --git a/docs/installation.rst b/docs/installation.rst index 2becc63..288f12b 100644 --- a/docs/installation.rst +++ b/docs/installation.rst @@ -21,8 +21,8 @@ That's it! Once enabled, ``channels`` will integrate itself into Django and take control of the ``runserver`` command. See :doc:`getting-started` for more. -Installing the lastest development version ------------------------------------------- +Installing the latest development version +----------------------------------------- To install the latest version of Channels, clone the repo, change to the repo, change to the repo directory, and pip install it into your current virtual diff --git a/docs/message-standards.rst b/docs/message-standards.rst index 44d4852..927d3b0 100644 --- a/docs/message-standards.rst +++ b/docs/message-standards.rst @@ -15,7 +15,7 @@ the received data (or something else based on ``reply_channel``). All messages must be able to be encoded as JSON; channel backends don't necessarily have to use JSON, but we consider it the lowest common denominator -for serialisation format compatability. +for serialisation format compatibility. The size limit on messages is 1MB (while channel backends may support larger sizes, all message formats should stay under this limit, which might include diff --git a/docs/releases/0.8.rst b/docs/releases/0.8.rst index ddeac26..9c4d15c 100644 --- a/docs/releases/0.8.rst +++ b/docs/releases/0.8.rst @@ -13,7 +13,7 @@ more efficient and user friendly: added to allow moving the user details from the HTTP session to the channel session in the ``connect`` consumer. * A ``@linearize`` decorator was added to help ensure a ``connect``/``receive`` pair are not executed - simultanously on two different workers. + simultaneously on two different workers. * Channel backends gained locking mechanisms to support the ``linearize`` feature. diff --git a/docs/scaling.rst b/docs/scaling.rst index 3bedf23..71cfd98 100755 --- a/docs/scaling.rst +++ b/docs/scaling.rst @@ -1,7 +1,7 @@ Scaling ======= -Of course, one of the downsides of introducing a channel layer to Django it +Of course, one of the downsides of introducing a channel layer to Django is that it's something else that must scale. Scaling traditional Django as a WSGI application is easy - you just add more servers and a loadbalancer. Your database is likely to be the thing that stopped scaling before, and there's