httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Issac Goldstand <>
Subject Re: svn commit: r468373 - in /httpd/httpd/trunk: CHANGES modules/cache/mod_cache.c modules/cache/mod_cache.h modules/cache/mod_disk_cache.c modules/cache/mod_disk_cache.h modules/cache/mod_mem_cache.c
Date Mon, 30 Oct 2006 17:55:36 GMT
Justin Erenkrantz wrote:
> On 10/30/06, Issac Goldstand <> wrote:
>> Looking at provider.c, a couple of questions spring to mind:
>> 1) Why isn't this part of apr-util? (it seems similar to apr_optional.h
>> - just intended for vtables rather than functions, and with this version
>> info)
> apr_optional is an ugly hack without a good API.  =)

Point still stands, though, that this might still fit there.

> The generic provider code grew out of mod_dav's provider interface.
> The aaa modules also uses this same interface as well.

Right, I saw those this morning when I looked at provider.c

>> 2) It seems that if trunk would want to use version "1" and fallback to
>> "0", the control logic for that would need to be in
>> ap_cache_get_providers and would need to check every version string
>> mod_cache is interested in (for an exact string match, unless the hash
>> function's doing something funky).  Wouldn't it be smarter to use a
>> numeric version and simply have ap_lookup_provider simply return the
>> provider of the requested group/type with the highest id?
> Yes, ap_cache_get_providers() would have the logic for checking "0"
> and "1" versions.  Note that the APR hash abstraction that the
> provider is built on top of only works with strings - not integers.
> The general provider API is intended to only return specific versions
> that it's asked for.
> Let me explain...
>> It would make
>> custom 3rd party modules easier to write too; we could define, say 10000
>> as PROVIDER_ID_CUSTOM, making it easier to write add-ons to modules
>> which use the provider interface to just write new providers with that
>> ID (or that ID +1 or -1) rather than having to both write the new
>> provider and also change the code which calls ap_lookup_provider to
>> request the new provider version.  Or did I miss the point somewhere?
> Nah, that's not the point - you use the name value of the provider for
> third-party modules.  The version number is fixed across all providers
> (generally).
> If I implement version "0" of the cache interface say in
> mod_disk_cache, then I call ap_register_provider() with version "0"
> with the name "disk".  In a hypothetical mod_large_disk_cache that
> implements version "1" of the cache interface, I then register version
> "1" with the name "thumper" (say).
> mod_cache is then taught how to handle version "0" and "1" providers.
> The user comes along with the following directive:
>  CacheEnable thumper /
> mod_cache will then look up "thumper" version "1" and then "0".  It'll
> find version "1" of the vtable and use that for its cache.
> However, if we wanted to do so, "thumper" could also register as
> "disk" version "1".  So, a mod_cache that understands version "1"
> would use mod_large_disk_cache instead of mod_disk_cache (which
> doesn't implement version "0") if it understands version "1"
> providers.
> I hope this makes it a bit clearer.  -- justin

It did.  I think I need to digest it a bit more. I completely understand
the logic of using provider names for third-party stuff, but some little
voice in the back of my mind is still nagging me about the versioning
logic; it's just going to be a pain to repeat the selection code for
every module (eg, dav, aaa) that wants to bump a version and would be
easier if the API just did it for you.  Can't have everything, I guess...

Regardless, many thanks for the insight!


View raw message