[Catalyst-commits] r14487 - trunk/examples/CatalystAdvent/root/2013

[jnapiorkowski at dev.catalyst.perl.org]

Author: jnapiorkowski
Date: 2013-12-12 17:39:51 +0000 (Thu, 12 Dec 2013)
New Revision: 14487

Modified:
   trunk/examples/CatalystAdvent/root/2013/12.pod
Log:
fixed some typos

Modified: trunk/examples/CatalystAdvent/root/2013/12.pod
===================================================================
--- trunk/examples/CatalystAdvent/root/2013/12.pod	2013-12-12 00:30:34 UTC (rev 14486)
+++ trunk/examples/CatalystAdvent/root/2013/12.pod	2013-12-12 17:39:51 UTC (rev 14487)
@@ -1,10 +1,10 @@
-=head1 Nonblocking and Streaming - Part 3
+=head1 Title Nonblocking and Streaming - Part 3
 
 =head1 Overview
 
 Modern versions of L<Catalyst> allow you to take charge of how your
 write operations work.  This enables better support for working inside
-common event loops such as L<AnyEvent> and <IO::Async> to support
+common event loops such as L<AnyEvent> and L<IO::Async> to support
 non blocking writes to stream large files.
 
 Lets explore how L<PSGI> implements delayed and streaming responses
@@ -66,7 +66,7 @@
 register a callback (basically an anonymous subroutine) that gets 
 called when the I/O job is complete.  You can even register callbacks
 to handle exceptional events.  This means that instead of having a limited
-number of forked processes that can handled one connection each, you can
+number of forked processes that can handle one connection each, you can
 have many (limited by how your operating system is setup and what resources it
 has) connections all at once.  The trick here is that instead of doing
 one thing at a time, we have an event loop which manages a schedule of
@@ -104,7 +104,7 @@
 There's a number of popular systems for managing event loops under Perl,
 including L<POE>, L<AnyEvent> and L<IO::Async>.  For this example I choose
 to use L<AnyEvent>.  Let's break down the application and see what (if anything)
-this is buying use.
+this is buying us.
 
 First off, instead of just creating an infinite loop, we create an anonymous
 subroutine to encapsulate the L<AnyEvent> timer model.  If you look carefully
@@ -118,8 +118,8 @@
 the closure with the C<$writer> object.  This then starts a timer event, which
 every second runs the callback to output the time.
 
-So, how is this better than the shorter an more simple version that runs under
-L<Starman>?  This timer is not waiting a second between callback.  It not
+So, how is this better than the shorter and more simple version that runs under
+L<Starman>?  This timer is not waiting a second between callbacks.  It's not
 blocking the server.  As a result, the L<Twiggy> based server can accept many
 more connections than L<Starman> with relatively low overhead in doing so.
 Generally you can have hundreds or even thousands of concurrent connections
@@ -294,6 +294,6 @@
 
 =head1 Author
 
-John Napiorkowski L<jjnapiork at cpan.org|email:jjnapiork at cpan.org>
+John Napiorkowski L<email:jjnapiork at cpan.org>
 
 =cut