---------------------
PatchSet 4824 
Date: 2002/08/31 01:28:51
Author: rbcollins
Branch: esi
Tag: (none) 
Log:
beginning doco update

Members: 
	doc/Programming-Guide/prog-guide.sgml:1.20.2.1->1.20.2.2 

Index: squid/doc/Programming-Guide/prog-guide.sgml
===================================================================
RCS file: /cvsroot/squid-sf//squid/doc/Programming-Guide/prog-guide.sgml,v
retrieving revision 1.20.2.1
retrieving revision 1.20.2.2
diff -u -r1.20.2.1 -r1.20.2.2
--- squid/doc/Programming-Guide/prog-guide.sgml	11 Aug 2002 10:08:22 -0000	1.20.2.1
+++ squid/doc/Programming-Guide/prog-guide.sgml	31 Aug 2002 01:28:51 -0000	1.20.2.2
@@ -2,7 +2,7 @@
 <article>
 <title>Squid Programmers Guide</title>
 <author>Squid Developers</author>
-<date>$Id: prog-guide.sgml,v 1.20.2.1 2002/08/11 10:08:22 rbcollins Exp $</date>
+<date>$Id: prog-guide.sgml,v 1.20.2.2 2002/08/31 01:28:51 rbcollins Exp $</date>
 
 <abstract>
 Squid is a WWW Cache application developed by the National Laboratory
@@ -91,19 +91,41 @@
 	<P>
 Squid consists of the following major components
 
-<sect1>Client Side
+<sect1>Client Side Socket
 
 	<P>
 	Here new client connections are accepted, parsed, and
-	processed.  This is where we determine if the request is
-	a cache HIT, REFRESH, MISS, etc.  With HTTP/1.1 we may have
-	multiple requests from a single TCP connection.  Per-connection
-	state information is held in a data structure called
-	<em/ConnStateData/.  Per-request state information is stored
-	in the <em/clientHttpRequest/ structure.
+	reply data sent. Per-connection state information is helk
+	in a data structure called <em/ConnStateData/.  Per-request 
+	state information is stored in the <em/clientSocketContext/
+	structure. With HTTP/1.1 we may have multiple requests from
+	a single TCP connection.
+
+<sect1>Client Side Request
+	<P>
+	This is where requests are processed. We determine if the
+	request is to be redirected, if it passes access lists,
+	and setup the initial client stream for internal requests.
+	Temporary state for this processing is held in a 
+	<em/clientRequestContext/ struct.
+	
+<sect1>Client Side Reply	
+	<P>
+	This is where we determine if the request is cache HIT, 
+	REFRESH, MISS, etc. This involves querying the store 
+	(possibly multiple times) to work through Vary lists and
+	the list. Per-request state information is stored
+	in the <em/clientReplyContext/ structure.
+
+<sect1>Client Streams
+	<P>
+	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.
 
 <sect1>Server Side
-
 	<P>
 	These routines are responsible for forwarding cache misses
 	to other servers, depending on the protocol.  Cache misses
@@ -428,6 +450,12 @@
 	see <url        url="http://squid.nlanr.net/Squid/urn-support.html"
 	name="URN support in Squid">.
 
+<sect1>ESI
+	<P>
+	ESI is an implementation of Edge Side Includes (<url url="http://www.esi.org">.)
+	ESI is implemented as a client side stream and a small 
+	modification to client_side_reply.c to check whether
+	ESI should be inserted into the reply stream or not.
 
 <sect>External Programs