On 10/30/06, Issac Goldstand <[EMAIL PROTECTED]> 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. =) The generic provider code grew out of mod_dav's provider interface. The aaa modules also uses this same interface as well.
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
