Re: Current plan

rbb@covalent.net wrote:

> Great. You and I are on the same page. You posted something to new-httpd

:)

> I will post the filter when I get a chance to clean it up a bit more. I

One important thing I wanted the caching framework to handle is that of content negotiation. Previously the cache design in mod_proxy made the assumption that each URL had one possible return object, which is an incorrect assumtion. Trying to add kludges to handle this only made it all uglier and more difficult to understand.

The way I see it is that all cache entries should be stored by URL. If I want to retrieve a cache entry, I provide an URL and request headers. The cache then decides on the request headers whether a version of the cached object is in the cache. To place an entry in the cache, the response headers will determine whether the newly cached object should replace an existing object (if it's the same) or should be stored alongside the existing object (if the object is a different representation). At this stage various optimisations can be introduced giving the system a little added intelligence: If an uncompressed object is requested, and a compressed object is in the cache, then return the cached object via the decompression filter instead of return a cache MISS and generating the request from scratch.

How long till we see the code?

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related httpd.apache.org Links announce bugs cvs dev docs gui-dev modproxy-dev packagers testers Request more information about Pantek

Regards,
Graham

-- 
-----------------------------------------
minfrin@sharp.fm		"There's a moon
					over Bourbon Street
						tonight..."