Re: store_headers in memcache and diskcache
On Feb 9, 2008 4:18 PM, Issac Goldstand <[EMAIL PROTECTED]> wrote: > josh rotenberg wrote: > > Seems like switching the names around a la mod_proxy would sound > > better: mod_cache_disk, mod_cache_mem, mod_cache_memcached, etc. > > > > Ack. Pain in the ass But the man speaks sense. Really not so > happy with doing it now - even as a major bump... > > My personal opinions: > +1 on 3.x > -0 on 2.4 > > Issac Yeah, not really a short term expectation, just sayin' really ...
ping on mod_dns
Any volunteers to import mod_dns so I can eventually start hacking at it again (topic came up at work recently and I have a couple of feature ideas that I'd like to work on, but really don't want to have to work in my old svn + port changes to asf svn too)? AFAIK, we finished with the red tape already (please tell me off-list if I'm wrong) Issac
Re: store_headers in memcache and diskcache
josh rotenberg wrote: > Seems like switching the names around a la mod_proxy would sound > better: mod_cache_disk, mod_cache_mem, mod_cache_memcached, etc. > Ack. Pain in the ass But the man speaks sense. Really not so happy with doing it now - even as a major bump... My personal opinions: +1 on 3.x -0 on 2.4 Issac
Re: PATCH -- make the cache modules part of 'all'.
Justin Erenkrantz wrote: > On Feb 9, 2008 7:37 PM, Dirk-Willem van Gulik <[EMAIL PROTECTED]> wrote: > >> Unless you swap in some third party (memcached, distcache, commercial >> netapp) module. >> > > But, if we want a 'good' out-of-the-box experience, then it sounds > like we should enable mod_disk_cache too. Similarly, it wouldn't make > sense to have mod_proxy enabled if we don't enable http or ajp > providers by default either. =) -- justin > +1 FWIW Issac
Re: store_headers in memcache and diskcache
On Feb 9, 2008 9:04 AM, Justin Erenkrantz <[EMAIL PROTECTED]> wrote: > On Feb 9, 2008 5:36 AM, josh rotenberg <[EMAIL PROTECTED]> wrote: > > If you want to collaborate on the google project let me know and I can > > add you, or you can take over, or however. > > Or, better yet, how about adding mod_memcache_cache (gah - crappy > name) to trunk? There's no real reason why we shouldn't have it if > there are interested developers to work and maintain it. -- justin > Seems like switching the names around a la mod_proxy would sound better: mod_cache_disk, mod_cache_mem, mod_cache_memcached, etc. I don't have a problem with putting it in trunk assuming its a good candidate (I'll just have to get someone to apply my patches if I keep working on it). Josh
Re: Caching the useful headers
On 02/09/2008 08:49 PM, Ruediger Pluem wrote: On 02/09/2008 08:39 PM, Dirk-Willem van Gulik wrote: On Sat, 9 Feb 2008, Ruediger Pluem wrote: +return apr_table_make(pool, 10); +}; + Why this? Just some type of defensive programming if someone feeds in a t == NULL? If yes, I would prefer return NULL instead of creating an empty table. Garbage in, garbage out :-). That was my first approach as well. But then I noticed that the users of this functions virtually always will have to serialize/store the tables; or otherwise track them. So if we have 3 options - -if (r->headers_in) in = ap_cache_cacheable_hdrs_in( serialize(in) else mark a skip or something that you did not BTW: apr_is_empty_table would be an alternate check that would filter out both cases: r->headers_in NULL or empty. Regards Rüdiger
Re: Caching the useful headers
On 02/09/2008 08:39 PM, Dirk-Willem van Gulik wrote: On Sat, 9 Feb 2008, Ruediger Pluem wrote: +return apr_table_make(pool, 10); +}; + Why this? Just some type of defensive programming if someone feeds in a t == NULL? If yes, I would prefer return NULL instead of creating an empty table. Garbage in, garbage out :-). That was my first approach as well. But then I noticed that the users of this functions virtually always will have to serialize/store the tables; or otherwise track them. So if we have 3 options - - if (r->headers_in) in = ap_cache_cacheable_hdrs_in( serialize(in) else mark a skip or something that you did not - headers_in = ap_cache_cacheable_hdrs_in( if (headers_in) serialize(in) else mark a skip etc - headers_in = ap_cache_cacheable_hdrs_in serialize(headers_in) which can deal with empty arrays or we defer - and simply return null and have the respective serializes all deal with this. The advantage of returning null is that it is quicker to check for those serializers. But if I had to optimize - I'd rather do so on assuming an array - as in reality we have the headers virtually always ? This is my thought. I currently see no situation where we supply a NULL to ap_cache_cacheable_hdrs now or in the future (in most cases I would assume not even an empty table). So I think returning NULL in ap_cache_cacheable_hdrs in this situation and write the serializer in a way that it can handle a NULL table gracefully seems to be a quick and sufficient measure here to avoid segfaults. So I would vote for option 3. Regards Rüdiger
Re: Caching the useful headers
On Sat, 9 Feb 2008, Ruediger Pluem wrote: > > +return apr_table_make(pool, 10); > > +}; > > + > > Why this? Just some type of defensive programming if someone feeds in a t == > NULL? > If yes, I would prefer return NULL instead of creating an empty table. > Garbage in, garbage out :-). That was my first approach as well. But then I noticed that the users of this functions virtually always will have to serialize/store the tables; or otherwise track them. So if we have 3 options - - if (r->headers_in) in = ap_cache_cacheable_hdrs_in( serialize(in) else mark a skip or something that you did not - headers_in = ap_cache_cacheable_hdrs_in( if (headers_in) serialize(in) else mark a skip etc - headers_in = ap_cache_cacheable_hdrs_in serialize(headers_in) which can deal with empty arrays or we defer - and simply return null and have the respective serializes all deal with this. The advantage of returning null is that it is quicker to check for those serializers. But if I had to optimize - I'd rather do so on assuming an array - as in reality we have the headers virtually always ? > How about using @deprecated here instead of warning? .. > Style ... Will fix prior to commit. Dw.
Re: PATCH -- make the cache modules part of 'all'.
Justin Erenkrantz wrote: On Feb 9, 2008 7:37 PM, Dirk-Willem van Gulik <[EMAIL PROTECTED]> wrote: Unless you swap in some third party (memcached, distcache, commercial netapp) module. But, if we want a 'good' out-of-the-box experience, then it sounds like we should enable mod_disk_cache too. Similarly, it wouldn't make sense to have mod_proxy enabled if we don't enable http or ajp providers by default either. =) -- justin +1 -Paul
Re: PATCH -- make the cache modules part of 'all'.
On Feb 9, 2008 7:37 PM, Dirk-Willem van Gulik <[EMAIL PROTECTED]> wrote: > Unless you swap in some third party (memcached, distcache, commercial > netapp) module. But, if we want a 'good' out-of-the-box experience, then it sounds like we should enable mod_disk_cache too. Similarly, it wouldn't make sense to have mod_proxy enabled if we don't enable http or ajp providers by default either. =) -- justin
Re: PATCH -- make the cache modules part of 'all'.
On Feb 9, 2008, at 6:15 PM, Ruediger Pluem wrote: On 02/09/2008 04:28 PM, Dirk-Willem van Gulik wrote: Ok - so I think this compromise makes the most sense ALLeverything except demo, experimental and things like bucketeer, import/export filters. MOSTall the stable things - including the proxy modules (And given the questions on mailing lists and wiki's - that really is something people seem to exepct). And at the same exempt ssl because of crypto and mod_mem_cache as it has not had that much tender lover and care recently. Makes sense ? Dw. Index: modules/cache/config.m4 === --- modules/cache/config.m4(revision 620132) +++ modules/cache/config.m4(working copy) @@ -4,7 +4,7 @@ APACHE_MODPATH_INIT(cache) -APACHE_MODULE(file_cache, File cache, , , no) +APACHE_MODULE(file_cache, File cache) dnl # list of object files for mod_cache cache_objs="dnl @@ -19,8 +19,8 @@ cache_pqueue.lo dnl cache_hash.lo dnl " -APACHE_MODULE(cache, dynamic file caching, $cache_objs, , no) -APACHE_MODULE(disk_cache, disk caching module, , , no) +APACHE_MODULE(cache, dynamic file caching, $cache_objs, , yes) +APACHE_MODULE(disk_cache, disk caching module, , , most) Hm. Does this make sense? We now have the cache enabled by default, but no backend provider. Thus mod_cache cannot be used in this case. Unless you swap in some third party (memcached, distcache, commercial netapp) module. Only most / all / --enable-disk-cache give us mod_cache with at least one backend provider. Dw.
Re: store_headers in memcache and diskcache
On 02/09/2008 06:10 PM, Dirk-Willem van Gulik wrote: On Feb 9, 2008, at 6:06 PM, Justin Erenkrantz wrote: On Feb 9, 2008 6:00 PM, Dirk-Willem van Gulik <[EMAIL PROTECTED]> wrote: Whichever is easiest. Happy to plop it in there at google. As it has a while to go before we should/could offer this for inclusion at httpd/ apache. Well, it could be fleshed out in trunk - it won't be backported to 2.2.x (at least not soon), but there's no reason to keep it out of our tree - especially if you keep talking about it on [EMAIL PROTECTED] =) -- justin Hmm - we already have an underloved mod_memcache there -- and ideally a fair chunk of code in mod_disk_cache which really should migrate 'up' into mod_cache and cache_utils before we can clean up (even) mod_memcache. How about a development branch instead? Regards Rüdiger
Re: Caching the useful headers
On 02/09/2008 05:37 PM, Dirk-Willem van Gulik wrote:
On Feb 9, 2008, at 12:46 AM, Ruediger Pluem wrote:
Or we keep the old slightly odd names.
I currently see no essential need for these changes to be
backportable. So
I would prefer cleaning up the names. But there might be a compromise:
1. Make ap_cache_cacheable_hdrs a macro that is defined as
ap_cache_cacheable_hdrs_out
2. Leave ap_cache_cacheable_hdrs_out as is.
3. Create ap_cache_cacheable_headers_out / ap_cache_cacheable_headers_in
This should only require a minor bump.
Bit of grepping yields very few google hits on people using it. And with
the #define() we'll have the
issue going forward as well. How about below. And we wack the
ap_cache_cacheable_hdrs_out()
function on the next major bump.
IMHO both approaches are somewhat equivalent: They require a minor bump
now and a major as soon as we drop the ap_cache_cacheable_hdrs_out symbol
either by deleting it or by renaming ap_cache_cacheable_hdrs_out to
ap_cache_cacheable_headers and dropping the macro.
Dw.
Index: cache_util.c
===
--- cache_util.c(revision 620145)
+++ cache_util.c(working copy)
@@ -571,10 +571,10 @@
return apr_pstrdup(p, hashfile);
}
-/* Create a new table consisting of those elements from an input
+/* Create a new table consisting of those elements from an
* headers table that are allowed to be stored in a cache.
*/
-CACHE_DECLARE(apr_table_t *)ap_cache_cacheable_hdrs_out(apr_pool_t *pool,
+CACHE_DECLARE(apr_table_t *)ap_cache_cacheable_headers(apr_pool_t *pool,
apr_table_t *t,
server_rec *s)
{
@@ -582,12 +582,17 @@
char **header;
int i;
+if (t == NULL) {
+return apr_table_make(pool, 10);
+};
+
Why this? Just some type of defensive programming if someone feeds in a t ==
NULL?
If yes, I would prefer return NULL instead of creating an empty table.
Garbage in, garbage out :-).
/* Make a copy of the headers, and remove from
* the copy any hop-by-hop headers, as defined in Section
* 13.5.1 of RFC 2616
*/
apr_table_t *headers_out;
headers_out = apr_table_copy(pool, t);
+
apr_table_unset(headers_out, "Connection");
apr_table_unset(headers_out, "Keep-Alive");
apr_table_unset(headers_out, "Proxy-Authenticate");
@@ -608,3 +613,46 @@
}
return headers_out;
}
+
+/* Legacy call - functionally equivalent to ap_cache_cacheable_headers.
+ * @warning this call will possibly be removed on the next API bump.
How about using @deprecated here instead of warning?
+ */
+CACHE_DECLARE(apr_table_t *)ap_cache_cacheable_hdrs_out(apr_pool_t *pool,
+apr_table_t *t,
+server_rec *s)
+{
+return ap_cache_cacheable_headers(p,t,s);
Style nitpick:
return ap_cache_cacheable_headers(p, t, s);
Index: mod_cache.c
===
--- mod_cache.c(revision 620145)
+++ mod_cache.c(working copy)
@@ -752,10 +752,12 @@
* However, before doing that, we need to first merge in
* err_headers_out and we also need to strip any hop-by-hop
* headers that might have snuck in.
+ *
+ * XX check -- we're not patching up content-type.
Style: Indenting
*/
r->headers_out = apr_table_overlay(r->pool, r->headers_out,
r->err_headers_out);
-r->headers_out = ap_cache_cacheable_hdrs_out(r->pool,
r->headers_out,
+r->headers_out = ap_cache_cacheable_headers(r->pool,
r->headers_out,
r->server);
apr_table_clear(r->err_headers_out);
Index: mod_cache.h
===
--- mod_cache.h(revision 620145)
+++ mod_cache.h(working copy)
@@ -288,9 +288,27 @@
const char *key, char **val);
CACHE_DECLARE(const char *)ap_cache_tokstr(apr_pool_t *p, const char
*list, const char **str);
-/* Create a new table consisting of those elements from a request_rec's
- * headers_out that are allowed to be stored in a cache
+* Create a new table consisting of those elements from an
Style: Indenting
+ * headers table that are allowed to be stored in a cache.
*/
+CACHE_DECLARE(apr_table_t *)ap_cache_cacheable_headers(apr_pool_t *pool,
+apr_table_t *t,
+server_rec *s);
+
+/* Create a new table consisting of those elements from an input
+ * headers table that are allowed to be stored in a cache.
+ */
+CACHE_DECLARE(apr_table_t *)ap_cache_cacheable_headers_in(request_rec *
r);
+
+/* Create
Re: PATCH -- make the cache modules part of 'all'.
On 02/09/2008 04:28 PM, Dirk-Willem van Gulik wrote: Ok - so I think this compromise makes the most sense ALLeverything except demo, experimental and things like bucketeer, import/export filters. MOSTall the stable things - including the proxy modules (And given the questions on mailing lists and wiki's - that really is something people seem to exepct). And at the same exempt ssl because of crypto and mod_mem_cache as it has not had that much tender lover and care recently. Makes sense ? Dw. Index: modules/cache/config.m4 === --- modules/cache/config.m4(revision 620132) +++ modules/cache/config.m4(working copy) @@ -4,7 +4,7 @@ APACHE_MODPATH_INIT(cache) -APACHE_MODULE(file_cache, File cache, , , no) +APACHE_MODULE(file_cache, File cache) dnl # list of object files for mod_cache cache_objs="dnl @@ -19,8 +19,8 @@ cache_pqueue.lo dnl cache_hash.lo dnl " -APACHE_MODULE(cache, dynamic file caching, $cache_objs, , no) -APACHE_MODULE(disk_cache, disk caching module, , , no) +APACHE_MODULE(cache, dynamic file caching, $cache_objs, , yes) +APACHE_MODULE(disk_cache, disk caching module, , , most) Hm. Does this make sense? We now have the cache enabled by default, but no backend provider. Thus mod_cache cannot be used in this case. Only most / all / --enable-disk-cache give us mod_cache with at least one backend provider. Regards Rüdiger
Re: store_headers in memcache and diskcache
On Feb 9, 2008, at 6:06 PM, Justin Erenkrantz wrote: On Feb 9, 2008 6:00 PM, Dirk-Willem van Gulik <[EMAIL PROTECTED]> wrote: Whichever is easiest. Happy to plop it in there at google. As it has a while to go before we should/could offer this for inclusion at httpd/ apache. Well, it could be fleshed out in trunk - it won't be backported to 2.2.x (at least not soon), but there's no reason to keep it out of our tree - especially if you keep talking about it on [EMAIL PROTECTED] =) -- justin Hmm - we already have an underloved mod_memcache there -- and ideally a fair chunk of code in mod_disk_cache which really should migrate 'up' into mod_cache and cache_utils before we can clean up (even) mod_memcache. Dw
Re: store_headers in memcache and diskcache
On Feb 9, 2008 6:00 PM, Dirk-Willem van Gulik <[EMAIL PROTECTED]> wrote: > Whichever is easiest. Happy to plop it in there at google. As it has a > while to go before we should/could offer this for inclusion at httpd/ > apache. Well, it could be fleshed out in trunk - it won't be backported to 2.2.x (at least not soon), but there's no reason to keep it out of our tree - especially if you keep talking about it on [EMAIL PROTECTED] =) -- justin
Re: store_headers in memcache and diskcache
On Feb 9, 2008 5:36 AM, josh rotenberg <[EMAIL PROTECTED]> wrote: > If you want to collaborate on the google project let me know and I can > add you, or you can take over, or however. Or, better yet, how about adding mod_memcache_cache (gah - crappy name) to trunk? There's no real reason why we shouldn't have it if there are interested developers to work and maintain it. -- justin
Re: store_headers in memcache and diskcache
On Feb 9, 2008, at 5:36 AM, josh rotenberg wrote: Dirk, my comments inline ... On Feb 8, 2008 11:19 AM, Dirk-Willem van Gulik <[EMAIL PROTECTED]> wrote: .. snip snip .. Ok - more or less merged a lot between both modules (2) --- al the good bits are yours :) Does that make sense to you ? Hah! Then there is a lot of work to do! Agreed - next step (I guess) is to isolate all the good things in mod- disk-cache; such as the two level hash on Vary - move this into general mod_cache and cache_util.c (i.e. to make sure that when you get a store_headers/body -- the vary info is handed to you on a silver platter already -- the server knows best). So that all cache modules can benefit here. .. - create/open -- we could fetch it all already then. - Or defer to the actual header/body routines - as you and I do now. - Or just 'punt' and store the thing as one big wack - as generally you are propably going to need both ? I struggled with this one a lot. In some ways an all or nothing approach seems better. Less setting and getting, its there or its not. Ok - I'll run some tests on a real server; to see what % gets headers but not bodies. I guess I was mainly trying to follow the mod_disk_cache model, and in some ways conform to what the provider api for caching seems to assume, that the two are separate. I think I was also discussing with someone the possibility of having body data auto-populate in the cache (via something completely outside of apache) and it sounded cool to be able to dump content into the cache without having to worry about faking up a header entry. And/or the possibility of allowing headers Right -- and/or having an external process (or even a near zero cost listener) be able to update or invalidate entries. and bodies to be stored in different servers/pools, so that perhaps header info is expiring or LRU'ing at a different rate. Just thoughts, really, though, not sure if it makes sense to overdesign for it. If you want to collaborate on the google project let me know and I can add you, or you can take over, or however. Whichever is easiest. Happy to plop it in there at google. As it has a while to go before we should/could offer this for inclusion at httpd/ apache. Dw
Re: Caching the useful headers
On Feb 9, 2008, at 12:46 AM, Ruediger Pluem wrote:
Or we keep the old slightly odd names.
I currently see no essential need for these changes to be
backportable. So
I would prefer cleaning up the names. But there might be a compromise:
1. Make ap_cache_cacheable_hdrs a macro that is defined as
ap_cache_cacheable_hdrs_out
2. Leave ap_cache_cacheable_hdrs_out as is.
3. Create ap_cache_cacheable_headers_out /
ap_cache_cacheable_headers_in
This should only require a minor bump.
Bit of grepping yields very few google hits on people using it. And
with the #define() we'll have the
issue going forward as well. How about below. And we wack the
ap_cache_cacheable_hdrs_out()
function on the next major bump.
Dw.
Index: cache_util.c
===
--- cache_util.c(revision 620145)
+++ cache_util.c(working copy)
@@ -571,10 +571,10 @@
return apr_pstrdup(p, hashfile);
}
-/* Create a new table consisting of those elements from an input
+/* Create a new table consisting of those elements from an
* headers table that are allowed to be stored in a cache.
*/
-CACHE_DECLARE(apr_table_t *)ap_cache_cacheable_hdrs_out(apr_pool_t
*pool,
+CACHE_DECLARE(apr_table_t *)ap_cache_cacheable_headers(apr_pool_t
*pool,
apr_table_t
*t,
server_rec *s)
{
@@ -582,12 +582,17 @@
char **header;
int i;
+if (t == NULL) {
+ return apr_table_make(pool, 10);
+};
+
/* Make a copy of the headers, and remove from
* the copy any hop-by-hop headers, as defined in Section
* 13.5.1 of RFC 2616
*/
apr_table_t *headers_out;
headers_out = apr_table_copy(pool, t);
+
apr_table_unset(headers_out, "Connection");
apr_table_unset(headers_out, "Keep-Alive");
apr_table_unset(headers_out, "Proxy-Authenticate");
@@ -608,3 +613,46 @@
}
return headers_out;
}
+
+/* Legacy call - functionally equivalent to ap_cache_cacheable_headers.
+ * @warning this call will possibly be removed on the next API bump.
+ */
+CACHE_DECLARE(apr_table_t *)ap_cache_cacheable_hdrs_out(apr_pool_t
*pool,
+apr_table_t *t,
+server_rec *s)
+{
+return ap_cache_cacheable_headers(p,t,s);
+}
+
+
+/* Create a new table consisting of those elements from an input
+ * headers table that are allowed to be stored in a cache.
+ */
+CACHE_DECLARE(apr_table_t *)ap_cache_cacheable_headers_in(request_rec
* r)
+{
+ return ap_cache_cacheable_hdrs(r->pool, r->headers_in, r->server);
+}
+
+/* Create a new table consisting of those elements from an output
+ * headers table that are allowed to be stored in a cache;
+ * ensure there is a content type and capture any errors.
+ */
+CACHE_DECLARE(apr_table_t
*)ap_cache_cacheable_headers_out(request_rec * r)
+{
+ apr_table_t *headers_out;
+
+ headers_out = ap_cache_cacheable_hdrs(r->pool, r->headers_out,
+ r->server);
+
+if (!apr_table_get(headers_out, "Content-Type")
+&& r->content_type) {
+apr_table_setn(headers_out, "Content-Type",
+ ap_make_content_type(r, r->content_type));
+}
+
+headers_out = apr_table_overlay(r->pool, headers_out,
+r->err_headers_out);
+
+ return headers_out;
+}
+
Index: mod_cache.c
===
--- mod_cache.c (revision 620145)
+++ mod_cache.c (working copy)
@@ -752,10 +752,12 @@
* However, before doing that, we need to first merge in
* err_headers_out and we also need to strip any hop-by-hop
* headers that might have snuck in.
+ *
+* XX check -- we're not patching up content-type.
*/
r->headers_out = apr_table_overlay(r->pool, r->headers_out,
r->err_headers_out);
-r->headers_out = ap_cache_cacheable_hdrs_out(r->pool, r-
>headers_out,
+r->headers_out = ap_cache_cacheable_headers(r->pool, r-
>headers_out,
r->server);
apr_table_clear(r->err_headers_out);
Index: mod_disk_cache.c
===
--- mod_disk_cache.c(revision 620145)
+++ mod_disk_cache.c(working copy)
@@ -922,17 +922,8 @@
if (r->headers_out) {
apr_table_t *headers_out;
-headers_out = ap_cache_cacheable_hdrs_out(r->pool, r-
>headers_out,
- r->server);
+headers_out = ap_cache_cacheable_headers_out(r);
-if (!apr_table_get(headers_out, "Content-Type")
-&& r->content_type) {
-
Re: PATCH -- make the cache modules part of 'all'.
Ok - so I think this compromise makes the most sense ALL everything except demo, experimental and things like bucketeer, import/export filters. MOSTall the stable things - including the proxy modules (And given the questions on mailing lists and wiki's - that really is something people seem to exepct). And at the same exempt ssl because of crypto and mod_mem_cache as it has not had that much tender lover and care recently. Makes sense ? Dw. Index: CHANGES === --- CHANGES (revision 620135) +++ CHANGES (working copy) @@ -2,6 +2,11 @@ Changes with Apache 2.3.0 [ When backported to 2.2.x, remove entry from this file ] + *) The configuration directive --enable-modules=MODULE-LIST and + --enable-mods-shared "ALL" now includes all modules but + mod_ssl and the experimental/debug modules. 'Most' now also + includes the proxy modules and mod_disk_cache. + Index: modules/proxy/config.m4 === --- modules/proxy/config.m4 (revision 620132) +++ modules/proxy/config.m4 (working copy) @@ -7,7 +7,7 @@ elif test "$enable_proxy" = "yes"; then proxy_mods_enable=yes else - proxy_mods_enable=no + proxy_mods_enable=most fi proxy_objs="mod_proxy.lo proxy_util.lo" Index: modules/cache/config.m4 === --- modules/cache/config.m4 (revision 620132) +++ modules/cache/config.m4 (working copy) @@ -4,7 +4,7 @@ APACHE_MODPATH_INIT(cache) -APACHE_MODULE(file_cache, File cache, , , no) +APACHE_MODULE(file_cache, File cache) dnl # list of object files for mod_cache cache_objs="dnl @@ -19,8 +19,8 @@ cache_pqueue.lo dnl cache_hash.lo dnl " -APACHE_MODULE(cache, dynamic file caching, $cache_objs, , no) -APACHE_MODULE(disk_cache, disk caching module, , , no) +APACHE_MODULE(cache, dynamic file caching, $cache_objs, , yes) +APACHE_MODULE(disk_cache, disk caching module, , , most) APACHE_MODULE(mem_cache, memory caching module, $mem_cache_objs, , no) APACHE_MODPATH_FINISH 4x4:httpd-trunk dirkx$ vi CHANGES 4x4:httpd-trunk dirkx$ svn diff Index: CHANGES === --- CHANGES (revision 620135) +++ CHANGES (working copy) @@ -2,6 +2,12 @@ Changes with Apache 2.3.0 [ When backported to 2.2.x, remove entry from this file ] + *) The configuration directive --enable-modules=MODULE-LIST and + --enable-mods-shared "ALL" now includes all modules but + mod_ssl and the experimental/debug modules. 'Most' now also + includes the proxy modules and mod_disk_cache. mod_memory_cache + is still 'no' - as maintenance lags. [Dirk-Willem van Gulik] + *) Also install mod_so.h, mod_rewrite.h and mod_cache.h; as these contain public function declarations which are useful for third party module authors [Dirk-Willem van Gulik]. Index: modules/proxy/config.m4 === --- modules/proxy/config.m4 (revision 620132) +++ modules/proxy/config.m4 (working copy) @@ -7,7 +7,7 @@ elif test "$enable_proxy" = "yes"; then proxy_mods_enable=yes else - proxy_mods_enable=no + proxy_mods_enable=most fi proxy_objs="mod_proxy.lo proxy_util.lo" Index: modules/cache/config.m4 === --- modules/cache/config.m4 (revision 620132) +++ modules/cache/config.m4 (working copy) @@ -4,7 +4,7 @@ APACHE_MODPATH_INIT(cache) -APACHE_MODULE(file_cache, File cache, , , no) +APACHE_MODULE(file_cache, File cache) dnl # list of object files for mod_cache cache_objs="dnl @@ -19,8 +19,8 @@ cache_pqueue.lo dnl cache_hash.lo dnl " -APACHE_MODULE(cache, dynamic file caching, $cache_objs, , no) -APACHE_MODULE(disk_cache, disk caching module, , , no) +APACHE_MODULE(cache, dynamic file caching, $cache_objs, , yes) +APACHE_MODULE(disk_cache, disk caching module, , , most) APACHE_MODULE(mem_cache, memory caching module, $mem_cache_objs, , no)
Re: PATCH: httpd-trunk -- add mod_cache.h to the header list installed in include/
On Feb 8, 2008, at 6:09 PM, Takashi Sato wrote: mod_rewrite.h and mod_so.h is also missing, and there might be other missings. Ok ! And ap_find_loaded_module_symbol() is indeed useful elsewhere. Dw.
