You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modproxy-dev@apache.org by Chuck Murcko <ch...@topsail.org> on 2000/11/12 03:12:25 UTC
Current plan
...is to remove BUFF, change <Directory> to <Location>, and then start
converting to filters a la Ryan's thoughts on the subject. Anyone else
here?
--
Chuck
Chuck Murcko
Topsail Group
chuck@topsail.org
Re: Current plan
Posted by Graham Leggett <mi...@sharp.fm>.
rbb@covalent.net wrote:
> > How long till we see the code?
>
> Depends on some other projects I have to do. I would hope to post the
> code either late today or tomorrow sometime.
Cool - I need some sleep (too much time driving around the M25 in London
for hours and hours), will take a look again when I am more awake.
Regards,
Graham
--
-----------------------------------------
minfrin@sharp.fm "There's a moon
over Bourbon Street
tonight..."
Re: Current plan
Posted by rb...@covalent.net.
> 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.
Sounds good to me.
> 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?
Depends on some other projects I have to do. I would hope to post the
code either late today or tomorrow sometime.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: Current plan
Posted by Graham Leggett <mi...@sharp.fm>.
rbb@covalent.net wrote:
> Great. You and I are on the same page. You posted something to new-httpd
> about a new caching framework, that uses filters. Let me add to it. :-)
:)
> I will post the filter when I get a chance to clean it up a bit more. I
> am not going to bother putting in the logic to figure out the correct
> filename for the cache, but I do want to make it obvious how different
> data stores can be plugged in.
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?
Regards,
Graham
--
-----------------------------------------
minfrin@sharp.fm "There's a moon
over Bourbon Street
tonight..."
Re: Current plan
Posted by rb...@covalent.net.
> So far many of the caching thoughts that have gone past haven't taken
> into account that HTTP/1.1 handles caches and inline proxies anyway. I'm
> strongly in favour of developing a general HTTP/1.1 caching framework
> because it will work everywhere within Apache.
>
> Currently there is talk of the caching in what will become the new
> mod_proxy, as well as the caching involved in mod_mmap_static (and
> mod_file_cache, which I understand is basically a replacement for
> mod_mmap_static?). One framework will cover all of these in one go.
Great. You and I are on the same page. You posted something to new-httpd
about a new caching framework, that uses filters. Let me add to it. :-)
Basically, the current cache is a hack, and we need to remove it. The
basic design for the cache should be simple, we are allowed to cache
anything, including the output of a php function call. To do this, we
have a very light-weight cache framework, that does garbage collection.
The actual cache'ing work is done with a single cache filter (basically
written and working). To cache to different data stores, you just use a
different plug-in to the filter. I am thinking that just the write and
read functions need to be replaced for each plug-in. This will look
seamless to the user. Oh, I guess we also need to plug-in different
remove functions so that we can do GC sanely.
I will post the filter when I get a chance to clean it up a bit more. I
am not going to bother putting in the logic to figure out the correct
filename for the cache, but I do want to make it obvious how different
data stores can be plugged in.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: Current plan
Posted by Graham Leggett <mi...@sharp.fm>.
rbb@covalent.net wrote:
> I have looked at integrating it into our current file_cache work, but my
> gut is that the file_cache module is too complex right now. I am
> considering a re-write to make it much simpler.
>
> Thoughts?
So far many of the caching thoughts that have gone past haven't taken
into account that HTTP/1.1 handles caches and inline proxies anyway. I'm
strongly in favour of developing a general HTTP/1.1 caching framework
because it will work everywhere within Apache.
Currently there is talk of the caching in what will become the new
mod_proxy, as well as the caching involved in mod_mmap_static (and
mod_file_cache, which I understand is basically a replacement for
mod_mmap_static?). One framework will cover all of these in one go.
Regards,
Graham
--
Re: Current plan
Posted by rb...@covalent.net.
I should mention that I have a caching filter written already. All it
does is write the data to the disk. It is a completely separate module
that doesn't hook into the current cache design at all. In fact, the
whole module is a hack, because it always writes the cache to the same
file, just overwriting the old cache.
I have looked at integrating it into our current file_cache work, but my
gut is that the file_cache module is too complex right now. I am
considering a re-write to make it much simpler.
Thoughts?
Ryan
On Mon, 13 Nov 2000, Graham Leggett wrote:
> Chuck Murcko wrote:
>
> > ...is to remove BUFF, change <Directory> to <Location>, and then start
> > converting to filters a la Ryan's thoughts on the subject. Anyone else
> > here?
>
> Did you get my draft design for a new set of caching filters? I've been
> snowed under lately, I've been wanting to update the design so that it
> is more specific.
>
> I'll post it again here, as this is where it should be discussed.
>
> Regards,
> Graham
> --
> -----------------------------------------
> minfrin@sharp.fm "There's a moon
> over Bourbon Street
> tonight..."
>
>
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: Current plan
Posted by Graham Leggett <mi...@sharp.fm>.
Chuck Murcko wrote:
> ...is to remove BUFF, change <Directory> to <Location>, and then start
> converting to filters a la Ryan's thoughts on the subject. Anyone else
> here?
Did you get my draft design for a new set of caching filters? I've been
snowed under lately, I've been wanting to update the design so that it
is more specific.
I'll post it again here, as this is where it should be discussed.
Regards,
Graham
--
-----------------------------------------
minfrin@sharp.fm "There's a moon
over Bourbon Street
tonight..."