Revision: 14603
Author: adrian.chadd
Date: Thu Apr 15 22:58:09 2010
Log: Edited wiki page through web user interface.
http://code.google.com/p/lusca-cache/source/detail?r=14603
Modified:
/wiki/ProjectCacheLogicTidyup.wiki
=======================================
--- /wiki/ProjectCacheLogicTidyup.wiki Thu Apr 15 22:53:48 2010
+++ /wiki/ProjectCacheLogicTidyup.wiki Thu Apr 15 22:58:09 2010
@@ -1,4 +1,14 @@
#summary Tidy up and document the various caching logic bits that make up
Squid/Lusca
#labels Project
+= Overview =
+
The caching logic pathways are long, complicated and twisty. This project
will aim to first unwind a bit of the twistiness and document what is going
on. It won't try to rewrite or heavily modify things.
+
+= Background =
+
+The bulk of the caching logic actually sits inline with the client-side
request and reply processing. Part of the hit processing pathway involves
evaluating whether the stored object is still fresh; whether there's
variant or ETags to worry about and handling IMS revalidation.
+
+Some of the caching logic sits in the server-facing code (src/http.c.)
httpCachableReply() determines whether the reply is at all cachable based
on a few properties of the reply. A cachable reply on the server-side may
then be made non-cachable by the client-side logic.
+
+This all requires significant reorganisation and documentation. In
particular, the process flow of request and reply handling in the
client-side code requires a lot of attention.
--
You received this message because you are subscribed to the Google Groups
"lusca-commit" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/lusca-commit?hl=en.
