Fixes to the progdoc.

1 files changed, 11 insertions, 11 deletions

diff --git a/doc/prog-intro.sgml b/doc/prog-intro.sgml
index ac45ab24..f584f69b 100644
--- a/doc/prog-intro.sgml
+++ b/doc/prog-intro.sgml
@@ -2,12 +2,12 @@
 
 <sect>Introduction
 
-<p>This document describes the internal workings of the BIRD, its architecture,
+<p>This document describes the internal workings of BIRD, its architecture,
 design decisions and rationale behind them. It also contains documentation on
 all the essential components of the system and their interfaces.
 
 <p>Routing daemons are very complicated things which need to act in real time
-to complex sequences external events, react correctly even to the most erroneous behavior
+to complex sequences of external events, respond correctly even to the most erroneous behavior
 of their environment and still handle enormous amount of data with reasonable
 speed. Due to all of this, their design is very tricky as one needs to carefully
 balance between efficiency, stability and (last, but not least) simplicity of
@@ -21,7 +21,7 @@ by the program source itself together with comments contained therein.
 
 <p>When planning the architecture of BIRD, we've taken a close look at the other existing routing
 daemons and also at some of the operating systems used on dedicated routers, gathered all important
-features and added lots of new ones to overcome their shortcomings and better match the requirements
+features and added lots of new ones to overcome their shortcomings and to better match the requirements
 of routing in today's Internet: IPv6, policy routing, route filtering and so on. From this
 planning, the following set of design goals has arisen:
 
@@ -36,8 +36,8 @@ This leads to abstraction of IP addresses and operations on them.
 <item><it>Minimize OS dependent code to make porting as easy as possible.</it>
 Unfortunately, such code cannot be avoided at all as the details of communication with
 the IP stack differ from OS to OS and they often vary even between different
-versions of the same OS, but we can isolate such code in special modules and
-do the porting by changing just these modules.
+versions of the same OS. But we can isolate such code in special modules and
+do the porting by changing or replacing just these modules.
 Also, don't rely on specific features of various operating systems, but be able
 to make use of them if they are available.
 
@@ -62,7 +62,7 @@ to read the new configuration and smoothly adapt to it without disturbing parts
 the routing process which are not affected by the change.
 
 <item><it>Be able to be controlled online.</it>
-In addition to online reconfiguration, a routing daemon should be able to communicate
+In addition to the online reconfiguration, a routing daemon should be able to communicate
 with the user and with many other programs (primarily scripts used for network maintenance)
 in order to make it possible to inspect contents of routing tables, status of all
 routing protocols and also to control their behavior (i.e., it should be possible
@@ -71,7 +71,7 @@ this, we implement a simple command-line protocol based on those used by FTP and
 (that is textual commands and textual replies accompanied by a numeric code which makes
 them both readable to a human and easy to recognize in software).
 
-<item><it>Respond to all protocol events in real time.</it>
+<item><it>Respond to all events in real time.</it>
 A typical solution to this problem is to use lots of threads to separate the workings
 of all the routing protocols and also of the user interface parts and to hope that
 the scheduler will assign time to them in a fair enough manner. This is surely a good
@@ -88,18 +88,18 @@ the following types of modules:
 
 <descrip>
 
-<tagp>Core modules</tagp> implement the core functions of BIRD as taking care
+<tagp>Core modules</tagp> implement the core functions of BIRD: taking care
 of routing tables, keeping protocol status, interacting with the user using
 the Command-Line Interface (to be called CLI in the rest of this document)
 etc.
 
 <tagp>Library modules</tagp> form a large set of various library functions
 implementing several data abstractions, utility functions and also functions
-which are a part of standard libraries on some systems, but missing on other
+which are a part of the standard libraries on some systems, but missing on other
 ones.
 
 <tagp>Resource management modules</tagp> take care of resources, their allocation
-and automatic freeing when the module having requested them ceases to exist.
+and automatic freeing when the module having requested shuts itself down.
 
 <tagp>Configuration modules</tagp> are fragments of lexical analyzer,
 grammar rules and the corresponding snippets of C code. For each group
@@ -120,7 +120,7 @@ interface to the CLI.
 
 <sect>Implementation
 
-<p>BIRD has been written in GNU C. We've considered using of C++, but we've
+<p>BIRD has been written in GNU C. We've considered using C++, but we've
 preferred the simplicity and straightforward nature of C which gives us fine
 control over all implementation details and on the other hand enough
 instruments to build the abstractions we need.