Justin Erenkrantz wrote: > 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. =)
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! Issac
