---------------------
PatchSet 5206 
Date: 2007/08/09 05:48:32
Author: amosjeffries
Branch: docs
Tag: (none) 
Log:
Pull more client-streams docs into the source.
Small re-format to remove tabs.

Members: 
	doc/Programming-Guide/03_MajorComponents.dox:1.1.2.3->1.1.2.4 
	src/clientStream.h:1.7.28.1->1.7.28.2 

Index: squid3/doc/Programming-Guide/03_MajorComponents.dox
===================================================================
RCS file: /cvsroot/squid-sf//squid3/doc/Programming-Guide/Attic/03_MajorComponents.dox,v
retrieving revision 1.1.2.3
retrieving revision 1.1.2.4
diff -u -r1.1.2.3 -r1.1.2.4
--- squid3/doc/Programming-Guide/03_MajorComponents.dox	31 Jul 2007 04:29:06 -0000	1.1.2.3
+++ squid3/doc/Programming-Guide/03_MajorComponents.dox	9 Aug 2007 05:48:32 -0000	1.1.2.4
@@ -31,14 +31,6 @@
 	the list. Per-request state information is stored
 	in the clientReplyContext.
 
-\section ClientStreams Client Streams
-\par
-	These routines implement a unidirectional, non-blocking,
-	pull pipeline. They allow code to be inserted into the 
-	reply logic on an as-needed basis. For instance, 
-	transfer-encoding logic is only needed when sending a
-	HTTP/1.1 reply.
-
 \section ServerSide Server Side
 \par
 	These routines are responsible for forwarding cache misses
Index: squid3/src/clientStream.h
===================================================================
RCS file: /cvsroot/squid-sf//squid3/src/clientStream.h,v
retrieving revision 1.7.28.1
retrieving revision 1.7.28.2
diff -u -r1.7.28.1 -r1.7.28.2
--- squid3/src/clientStream.h	8 Aug 2007 02:30:59 -0000	1.7.28.1
+++ squid3/src/clientStream.h	9 Aug 2007 05:48:32 -0000	1.7.28.2
@@ -1,6 +1,6 @@
 
 /*
- * $Id: clientStream.h,v 1.7.28.1 2007/08/08 02:30:59 amosjeffries Exp $
+ * $Id: clientStream.h,v 1.7.28.2 2007/08/09 05:48:32 amosjeffries Exp $
  *
  *
  * SQUID Web Proxy Cache          http://www.squid-cache.org/
@@ -40,35 +40,42 @@
 /**
  * \defgroup ClientStreamAPI Client Streams
  * \ingroup Components
- 
+
 \section Introduction Introduction
 \par
-        A clientStream is a uni-directional loosely coupled pipe. Each node
-        consists of four methods - read, callback, detach, and status, along with the
-        stream housekeeping variables (a dlink node and pointer to the head of
-        the list), context data for the node, and read request parameters -
-        readbuf, readlen and readoff (in the body).
+    A ClientStream implement a unidirectional, non-blocking,
+    pull pipeline. They allow code to be inserted into the
+    reply logic on an as-needed basis. For instance,
+    transfer-encoding logic is only needed when sending a
+    HTTP/1.1 reply.
+
+    Each node consists of four methods - read, callback, detach, and status,
+    along with the stream housekeeping variables (a dlink node and pointer
+    to the head of the list), context data for the node, and read request
+    parameters - readbuf, readlen and readoff (in the body).
+
 \par
-        clientStream is the basic unit for scheduling, and the clientStreamRead
-        and clientStreamCallback calls allow for deferred scheduled activity if desired.
+    clientStream is the basic unit for scheduling, and the clientStreamRead
+    and clientStreamCallback calls allow for deferred scheduled activity if
+    desired.
 
 \par    Theory on stream operation:
-        \li     Something creates a pipeline. At a minimum it needs a head with a
-                status method and a read method, and a tail with a callback method and a
-                valid initial read request.
-        \li     Other nodes may be added into the pipeline.
-        \li     The tail-1th node's read method is called.
+    \li     Something creates a pipeline. At a minimum it needs a head with a
+            status method and a read method, and a tail with a callback method
+            and a valid initial read request.
+    \li     Other nodes may be added into the pipeline.
+    \li     The tail-1th node's read method is called.
 \par
-        For each node going up the pipeline, the node either:
-        \li             satisfies the read request, or
-        \li             inserts a new node above it and calls clientStreamRead, or
-        \li             calls clientStreamRead
+    For each node going up the pipeline, the node either:
+    \li             satisfies the read request, or
+    \li             inserts a new node above it and calls clientStreamRead, or
+    \li             calls clientStreamRead
 \todo DOCS: make the above list nested.
 
 \par
-        There is no requirement for the Read parameters from different
-        nodes to have any correspondence, as long as the callbacks provided are
-        correct.
+    There is no requirement for the Read parameters from different
+    nodes to have any correspondence, as long as the callbacks provided are
+    correct.
 
 \section WhatsInANode Whats in a node
 
@@ -76,7 +83,7 @@
 
 \par	Each node must have: 
 	\li	read method - to allow loose coupling in the pipeline. (The reader may
-		therefore change if the pipeline is altered, even mid-flow).
+			therefore change if the pipeline is altered, even mid-flow).
 	\li	callback method - likewise.
 	\li	status method - likewise.
 	\li	detach method - used to ensure all resources are cleaned up properly.