perl-docs-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From s...@apache.org
Subject cvs commit: modperl-docs/src/docs/2.0/user/handlers intro.pod
Date Wed, 26 Nov 2003 07:56:45 GMT
stas        2003/11/25 23:56:45

  Modified:    src/docs/2.0/user/handlers intro.pod
  Log:
  move the bucket brigades stuff to the end, as it doesn't quite fit where
  it was now
  
  Revision  Changes    Path
  1.15      +56 -63    modperl-docs/src/docs/2.0/user/handlers/intro.pod
  
  Index: intro.pod
  ===================================================================
  RCS file: /home/cvs/modperl-docs/src/docs/2.0/user/handlers/intro.pod,v
  retrieving revision 1.14
  retrieving revision 1.15
  diff -u -u -r1.14 -r1.15
  --- intro.pod	26 Nov 2003 07:55:48 -0000	1.14
  +++ intro.pod	26 Nov 2003 07:56:45 -0000	1.15
  @@ -213,69 +213,6 @@
   
   
   
  -=head1 Bucket Brigades
  -
  -Apache 2.0 allows multiple modules to filter both the request and the
  -response. Now one module can pipe its output as an input to another
  -module as if another module was receiving the data directly from the
  -TCP stream. The same mechanism works with the generated response.
  -
  -With I/O filtering in place, simple filters, like data compression and
  -decompression, can be easily implemented and complex filters, like
  -SSL, are now possible without needing to modify the the server code
  -which was the case with Apache 1.3.
  -
  -In order to make the filtering mechanism efficient and avoid
  -unnecessary copying, while keeping the data abstracted, the I<Bucket
  -Brigades> technology was introduced. It's also used in L<protocol
  -handlers|docs::2.0::user::handlers::protocols>.
  -
  -A bucket represents a chunk of data.  Buckets linked together comprise
  -a brigade. Each bucket in a brigade can be modified, removed and
  -replaced with another bucket. The goal is to minimize the data copying
  -where possible.  Buckets come in different types, such as files, data
  -blocks, end of stream indicators, pools, etc. To manipulate a bucket
  -one doesn't need to know its internal representation.
  -
  -The stream of data is represented by bucket brigades.  When a filter
  -is called it gets passed the brigade that was the output of the
  -previous filter. This brigade is then manipulated by the filter (e.g.,
  -by modifying some buckets) and passed to the next filter in the stack.
  -
  -The following figure depicts an imaginary bucket brigade:
  -
  -=for html
  -<img src="bucket_brigades.gif" width="590" height="400" 
  - align="middle" alt="bucket brigades"><br><br>
  -
  -The figure tries to show that after the presented bucket brigade has
  -passed through several filters some buckets were removed, some
  -modified and some added. Of course the handler that gets the brigade
  -cannot tell the history of the brigade, it can only see the existing
  -buckets in the brigade.
  -
  -Bucket brigades are discussed in detail in the L<protocol
  -handlers|docs::2.0::user::handlers::protocols> and L<I/O
  -filtering|docs::2.0::user::handlers::filters> chapters.
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
   
   
   
  @@ -399,6 +336,62 @@
   META: more information in mod_example.c talking about
   position/predecessors, etc.
   
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +=head1 Bucket Brigades
  +
  +Apache 2.0 allows multiple modules to filter both the request and the
  +response. Now one module can pipe its output as an input to another
  +module as if another module was receiving the data directly from the
  +TCP stream. The same mechanism works with the generated response.
  +
  +With I/O filtering in place, simple filters, like data compression and
  +decompression, can be easily implemented and complex filters, like
  +SSL, are now possible without needing to modify the the server code
  +which was the case with Apache 1.3.
  +
  +In order to make the filtering mechanism efficient and avoid
  +unnecessary copying, while keeping the data abstracted, the I<Bucket
  +Brigades> technology was introduced. It's also used in L<protocol
  +handlers|docs::2.0::user::handlers::protocols>.
  +
  +A bucket represents a chunk of data.  Buckets linked together comprise
  +a brigade. Each bucket in a brigade can be modified, removed and
  +replaced with another bucket. The goal is to minimize the data copying
  +where possible.  Buckets come in different types, such as files, data
  +blocks, end of stream indicators, pools, etc. To manipulate a bucket
  +one doesn't need to know its internal representation.
  +
  +The stream of data is represented by bucket brigades.  When a filter
  +is called it gets passed the brigade that was the output of the
  +previous filter. This brigade is then manipulated by the filter (e.g.,
  +by modifying some buckets) and passed to the next filter in the stack.
  +
  +The following figure depicts an imaginary bucket brigade:
  +
  +=for html
  +<img src="bucket_brigades.gif" width="590" height="400" 
  + align="middle" alt="bucket brigades"><br><br>
  +
  +The figure tries to show that after the presented bucket brigade has
  +passed through several filters some buckets were removed, some
  +modified and some added. Of course the handler that gets the brigade
  +cannot tell the history of the brigade, it can only see the existing
  +buckets in the brigade.
  +
  +Bucket brigades are discussed in detail in the L<protocol
  +handlers|docs::2.0::user::handlers::protocols> and L<I/O
  +filtering|docs::2.0::user::handlers::filters> chapters.
   
   
   
  
  
  

---------------------------------------------------------------------
To unsubscribe, e-mail: docs-cvs-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-cvs-help@perl.apache.org


Mime
View raw message