On Mon, Oct 30, 2006 at 09:51:30AM -0700, Justin Erenkrantz wrote: > >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.
So here's another assumption to consider with this work... I keep seeing people talk about the mod_cache interface as an externally-visible API for which we must maintain API/ABI compatibility. But mod_cache.h is not installed, so this API is not actually exposed externally, and never has been. Given that fact I don't see the point in jumping through hoops to maintain backwards API compat, only two modules use the API. joe
