cvs commit: apache-2.0/htdocs/manual/developer layeredio.html

[dr...@locus.apache.org]

dreid       00/03/26 01:39:36

  Modified:    htdocs/manual new_features_2_0.html
               htdocs/manual/developer layeredio.html
  Log:
  Fix a couple of typo's and add a link to the list of MPM's from the
  changes document.
  
  Revision  Changes    Path
  1.3       +2 -2      apache-2.0/htdocs/manual/new_features_2_0.html
  
  Index: new_features_2_0.html
  ===================================================================
  RCS file: /home/cvs/apache-2.0/htdocs/manual/new_features_2_0.html,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- new_features_2_0.html	2000/01/22 04:23:56	1.2
  +++ new_features_2_0.html	2000/03/26 09:39:36	1.3
  @@ -33,10 +33,10 @@
   <DT><STRONG>Better support for non-Unix platforms</STRONG>
   <DD>Apache 2.0 should be faster and more stable on non-Unix platforms such
       as BeOS, OS/2, and Windows. With the introduction of platform-specific
  -    multiprocessing modules and the Apache Portable Runtime, these
  +    multiprocessing modules (MPM) and the Apache Portable Runtime, these
       platforms can now avoid using POSIX-emulation functions that are
       sometimes buggy and always hurt performance.
  -
  +<DD>A list of the MPM's currently available is <a href="mpm.html">here</a>.
   <DT><STRONG>New API</STRONG>
   <DD>The API for modules has changed significantly for 2.0. Many of the
       module-ordering problems from 1.3 should be gone. 2.0 does much of
  
  
  
  1.2       +2 -2      apache-2.0/htdocs/manual/developer/layeredio.html
  
  Index: layeredio.html
  ===================================================================
  RCS file: /home/cvs/apache-2.0/htdocs/manual/developer/layeredio.html,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- layeredio.html	2000/03/25 15:45:01	1.1
  +++ layeredio.html	2000/03/26 09:39:36	1.2
  @@ -31,7 +31,7 @@
   When a handler returns this value, the core searches through the list of 
   handlers looking for another module that wants to try the request.
   
  -<P>When a module returns RERUN_HANDLERS, it must modify teo fields of the
  +<P>When a module returns RERUN_HANDLERS, it must modify two fields of the
   request_rec, the handler and content_type fields.  Most modules will
   set the handler field to NULL, and allow the core to choose the which 
   module gets run next.  If these two fields are not modified, then the server
  @@ -44,7 +44,7 @@
   the next module in the list.  A new function has been added, ap_setup_input,
   which all modules should call before they do any reading to get data to modify.
   This function checks to determine if the previous module set the input field,
  -if so, that input is used, if not the file is opend and that data source 
  +if so, that input is used, if not the file is opened and that data source 
   is used.  The output field is used basically the same way.  The module must
   set this field before they call ap_r* in order to take advantage of
   layered I/O.  If this field is not set, ap_r* will write directly to the