Justin Erenkrantz wrote:
On 10/30/06, Issac Goldstand <[EMAIL PROTECTED]> wrote:
Can you clarify the above a bit? I don't understand what you're
referring to. Looking at the 2.2.3 tag, what versioning is currently in
place?
Look at disk_cache_register_hook.
/* cache initializer */
ap_register_provider(p, CACHE_PROVIDER_GROUP, "disk", "0",
&cache_disk_provider);
The "0" is the version string with the cache_disk_provider vtable
acting as the 0 version..
When we have a new cache provider version (i.e. the vtable changes),
that gets bumped up to "1". Then, mod_cache can select a "0" or
"1"-class backend. Preferably, it should be able to use both; but
trunk would prefer "1" and fallback to "0" if it's not available.
Gotcha. Thanks for the insight.
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)
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? 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?
