Merge pull request #36 from pajusmar/master

Typos
This commit is contained in:
Andrew Godwin 2015-12-11 15:51:40 -08:00
commit 976faeca9a
6 changed files with 9 additions and 9 deletions

View File

@ -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.

View File

@ -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.

View File

@ -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

View File

@ -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

View File

@ -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.

View File

@ -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