[Checkins] SVN: zc.ngi/trunk/src/zc/ngi/doc/index.txt Fixed some spelling errors.

[Jim Fulton]

Log message for revision 114229:
  Fixed some spelling errors.
  

Changed:
  U   zc.ngi/trunk/src/zc/ngi/doc/index.txt

-=-
Modified: zc.ngi/trunk/src/zc/ngi/doc/index.txt
===================================================================
--- zc.ngi/trunk/src/zc/ngi/doc/index.txt	2010-07-06 10:35:28 UTC (rev 114228)
+++ zc.ngi/trunk/src/zc/ngi/doc/index.txt	2010-07-06 10:45:34 UTC (rev 114229)
@@ -33,7 +33,7 @@
 
 NGI defines 2 groups of interfaces: application and implementation.
 Application interfaces are implemented by people writing applications
-and application-level libraries calling implemenytion interfaces.
+and application-level libraries calling implementation interfaces.
 
 NGI is primarily an asynchronous event-driven networking library.  Applications
 provide handlers that respond to network events.  The application
@@ -153,7 +153,7 @@
 
 The ``zc.ngi.async`` module provides a collection of implementations
 based on the ``asyncore`` module from the Python standard library.
-These implentations differ based on the way they handle threads.
+These implementations differ based on the way they handle threads.
 Perhaps the simplest of these is the ``zc.ngi.async.main``
 implementation::
 
@@ -355,7 +355,7 @@
 One ``zc.ngi.async``-controlled loop In this model, the
     ``zc.ngi.async`` module maintains its own loop thread.  This is
     the default implementation, provided by the module itself.  It is
-    appropriate when implementingh libraries that perform networking
+    appropriate when implementing libraries that perform networking
     to perform their function. The advantage of this approach is that
     it is less intrusive to applications.  The loop thread is managed
     automatically.
@@ -373,7 +373,7 @@
     provide the :class:`~zc.ngi.interfaces.IImplementation` interface and
     each have their own networking loop, running in a separate thread.
     For example, if you have an application that has multiple network
-    servers or multiple long-lived clients, it can be desireable to run
+    servers or multiple long-lived clients, it can be desirable to run
     each using it's own implementation.
 
 Multiple ``zc.ngi.async`` implementations and application-managed threads
@@ -381,7 +381,7 @@
     the :class:`~zc.ngi.interfaces.IImplementation` interface and have
     a blocking loop method that you must call yourself.  Use this
     implementation class to manage threads yourself.  The loop method
-    returns when an exceptiuon is raised by a handler or when there
+    returns when an exception is raised by a handler or when there
     are no handlers registered with the implementation.
     ``zc.ngi.async.main`` is a ``zc.ngi.async.Inline`` instance.
 
@@ -390,7 +390,7 @@
 
 With a single loop, all networking activity is done in one thread.
 If a handler takes a long time to perform some function, it can
-prevent other networking activity from propceeding. For this reason,
+prevent other networking activity from proceeding. For this reason,
 when a single loop is used, it's important that handlers perform their
 work quickly, without blocking for any length of time.
 
@@ -400,7 +400,7 @@
 
 If you need to do a lot of work in response to network events,
 consider using multiple loops, or using thread pools (or
-multipprocessing pools) connected to your handlers with queues.
+multiprocessing pools) connected to your handlers with queues.
 
 Threads are heavier than handlers
 ---------------------------------
@@ -416,11 +416,11 @@
 
 We saw earlier that we implemented connection handlers by implementing
 the :class:`~zc.ngi.interfaces.IConnectionHandler` in a class that
-provided, at a minmimum, a ``handle_input`` method.  This is pretty
+provided, at a minimum, a ``handle_input`` method.  This is pretty
 straightforward.  The ``handle_input`` method simply reacts to input data.
-Unfortunately, for many applications, this can make applicatiomn logic
+Unfortunately, for many applications, this can make application logic
 harder to express.  Sometimes, a more imperative style leads to
-simpler applicatiuon logic.
+simpler application logic.
 
 Let's look at an example.  We'll implement a simple word-count server
 connection handler that implements something akin to the Unix ``wc``
@@ -524,14 +524,14 @@
   :class:`~zc.ngi.interfaces.IConnectionHandler` interface.  The
   optional methods are handled by throwing exceptions to the generator
   function.  A generator function can handle these events by
-  providingh exception handlers.
+  providing exception handlers.
 
 - The ``generator`` decorator creates an object that implements
   :class:`~zc.ngi.interfaces.IServer` and can be used as a server.
 
 - The ``generator`` decorator creates an object that minimally implements
   :class:`~zc.ngi.interfaces.IClientConnectHandler` and can be used as
-  a client connectioon handler, as described later.
+  a client connection handler, as described later.
 
 
 Implementing clients
@@ -676,7 +676,7 @@
 raises an exception.  For this reason, generator handlers are
 generally only appropriate in ad hoc situations, like simple client
 scripts, typically using ``zc.ngi.async.main``, where exceptions are
-propigated to the ``zc.ngi.async.main.loop`` call.
+propagated to the ``zc.ngi.async.main.loop`` call.
 
 Connecting
 ----------
@@ -985,7 +985,7 @@
 You may need to make a few networking requests in a script. You
 typically want to make the requests, block until they're done, and
 then go on about your business.  The ``zc.ngi.async`` implementations
-provide a ``wait`` method that can be used in this sitation. The
+provide a ``wait`` method that can be used in this situation. The
 `wait`` method blocks until there are no outstanding requests, or
 until an optional timeout has passed.