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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
