[Openvas-commits] r911 - trunk/doc/website

[scm-commit@wald.intevation.org]

Author: bh
Date: 2008-06-13 19:20:00 +0200 (Fri, 13 Jun 2008)
New Revision: 911

Modified:
   trunk/doc/website/openvas-cr-11.htm4
   trunk/doc/website/openvas-cr-9.htm4
Log:
Fix typos.


Modified: trunk/doc/website/openvas-cr-11.htm4
===================================================================
--- trunk/doc/website/openvas-cr-11.htm4	2008-06-13 07:53:56 UTC (rev 910)
+++ trunk/doc/website/openvas-cr-11.htm4	2008-06-13 17:20:00 UTC (rev 911)
@@ -34,7 +34,7 @@
 
 <p>
 To reduce code base of OpenVAS-Client by using storage, command line parsing and several
-other functionalities of glib instead and thus share the efford to maintain and optimize
+other functionalities of glib instead and thus share the effort to maintain and optimize
 base functionalities among a broader developer/user base.
 </p>
 
@@ -73,7 +73,7 @@
      the more functionality is moved over to glib the more complicated
      it will be to migrate to other APIs as glib does not implement
      any standard. In the case it should eventually be decided to
-     not link against the upstream glib anymore (e.g. it gets abandonend or
+     not link against the upstream glib anymore (e.g. it gets abandoned or
      badly maintained), then it would be necessary
      to maintain a copy of glib with only the relevant features
      inside OpenVAS. At least until it might be decided to migrate to other API(s).</li>
@@ -100,7 +100,7 @@
      See <a href="http://library.gnome.org/devel/glib/stable/glib-Commandline-option-parser.html">glib
      API for command line parsing</a>.
 
-<li> Remove any occurance and handling of the getopt copies.
+<li> Remove any occurrence and handling of the getopt copies.
 
 <li> Evaluate which of the <a href="http://library.gnome.org/devel/glib/stable/glib-data-types.html">
      GLib Data Types</a> to be used to replacing arglist and other data management.

Modified: trunk/doc/website/openvas-cr-9.htm4
===================================================================
--- trunk/doc/website/openvas-cr-9.htm4	2008-06-13 07:53:56 UTC (rev 910)
+++ trunk/doc/website/openvas-cr-9.htm4	2008-06-13 17:20:00 UTC (rev 911)
@@ -34,7 +34,7 @@
 
 <p>
 To reduce code base of OpenVAS by using storage, command line parsing and several
-other functionalities of glib instead and thus share the efford to maintain and optimize
+other functionalities of glib instead and thus share the effort to maintain and optimize
 base functionalities among a broader developer/user base.
 </p>
 
@@ -50,7 +50,7 @@
 OpenVAS includes several code elements that are either copies from third parties (e.g. getopt)
 or self-implemented solutions that re-implement already available solutions (e.g. arglist concept).
 Probably both was done with portability in mind. The latter perhaps aimed at having
-performance screws better under contol. However, these decisions were done many years
+performance screws better under control. However, these decisions were done many years
 ago in the Nessus times.
 </p>
 
@@ -70,12 +70,12 @@
 and an active developer community might offer better quality
 than a re-invented code under own control but which receives
 only little review. It is out of scope for OpenVAS to develop
-critria that enable to balance out advantages and disadvantages
+criteria that enable to balance out advantages and disadvantages
 of this design decision in general.
 </p>
 
 <p>
-The main issue to solve with glib is to use its functioanlity to
+The main issue to solve with glib is to use its functionality to
 replace all "arglist" based storage handling of OpenVAS in order
 to gain a better performance and less OpenVAS source code.
 Other gains could be to replace any "getopt" by the respective
@@ -92,7 +92,7 @@
 <li> The more functionality is moved over to glib the more complicated
      it will be to migrate to other APIs as glib does not implement
      any standard. In the case it should eventually be decided to
-     not link against the upstream glib anymore (e.g. it gets abandonend or
+     not link against the upstream glib anymore (e.g. it gets abandoned or
      badly maintained), then it would be necessary
      to maintain a copy of glib with only the relevant features
      inside OpenVAS. At least until it might be decided to migrate to other API(s).
@@ -119,7 +119,7 @@
      See <a href="http://library.gnome.org/devel/glib/stable/glib-Commandline-option-parser.html">glib
      API for command line parsing</a>.
 
-<li> Remove any occurance and handling of the getopt copies.
+<li> Remove any occurrence and handling of the getopt copies.
 
 <li> Evaluate whether the <a href="http://library.gnome.org/devel/glib/stable/glib-Random-Numbers.html">
      random number API</a> of glib should