cvs commit: modperl-docs/src/docs/2.0/user/handlers filters.pod protocols.pod

[st...@apache.org]

stas        2003/03/03 18:12:11

  Modified:    src/docs/2.0/user/handlers filters.pod protocols.pod
  Log:
  xref bb's and add reasons why one have to understand how they work
  
  Revision  Changes    Path
  1.14      +25 -6     modperl-docs/src/docs/2.0/user/handlers/filters.pod
  
  Index: filters.pod
  ===================================================================
  RCS file: /home/cvs/modperl-docs/src/docs/2.0/user/handlers/filters.pod,v
  retrieving revision 1.13
  retrieving revision 1.14
  diff -u -r1.13 -r1.14
  --- filters.pod	2 Mar 2003 13:29:40 -0000	1.13
  +++ filters.pod	4 Mar 2003 02:12:11 -0000	1.14
  @@ -17,13 +17,32 @@
   Apache 2.0 considers all incoming and outgoing data as chunks of
   information, disregarding their kind and source or storage
   methods. These data chunks are stored in I<buckets>, which form
  -I<bucket brigades>. Input and output filters massage the data in
  -I<bucket brigades>.
  +L<bucket
  +brigades|docs::2.0::user::handlers::intro/Bucket_Brigades>. Input and
  +output filters massage the data in I<bucket brigades>.
  +
  +mod_perl 2.0 filters can directly manipulate the bucket brigades or
  +use the simplified streaming interface where the filter object acts
  +similar to a filehandle, which can be read from and printed to.
  +
  +Even though you don't use bucket brigades directly when you use the
  +streaming filter interface (which works on bucket bridades behind the
  +scenes), it's still important to understand bucket brigades. For
  +example you need to know that an output filter will be invoked as many
  +times as the number of bucket brigades sent from the upstream filter
  +or content handler. Or you need to know that the end of stream
  +indicator (EOS) is sometimes sent in a separate bucket brigade, so it
  +shouldn't be a surprise that the filter was invoked even though no
  +real data went through. As we delve into the filter details you will
  +see that L<understanding bucket
  +brigades|docs::2.0::user::handlers::intro/Bucket_Brigades>, will help
  +to understand how filters work.
  +
  +Moreover you will need to understand bucket brigades if you plan to
  +implement L<protocol modules|docs::2.0::user::handlers::protocols>.
  +
  +
   
  -mod_perl 2.0 filters can work with raw data, directly manipulating the
  -bucket brigades or using the simplified streaming interface where the
  -filter object acts similar to a filehandle, which can be read from and
  -printed to.
   
   =head2 HTTP Request Versus Connection Filters
   
  
  
  
  1.5       +3 -2      modperl-docs/src/docs/2.0/user/handlers/protocols.pod
  
  Index: protocols.pod
  ===================================================================
  RCS file: /home/cvs/modperl-docs/src/docs/2.0/user/handlers/protocols.pod,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- protocols.pod	17 Feb 2003 09:43:21 -0000	1.4
  +++ protocols.pod	4 Mar 2003 02:12:11 -0000	1.5
  @@ -116,8 +116,9 @@
   
   Now let's look at the following two examples of connection
   handlers. The first using the connection socket to read and write the
  -data and the second using bucket brigades to accomplish the same and
  -allow for connection filters to do their work.
  +data and the second using L<bucket
  +brigades|docs::2.0::user::handlers::intro/Bucket_Brigades> to
  +accomplish the same and allow for connection filters to do their work.
   
   =head3 Socket-based Protocol Module