Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (herse.apache.org: domain of justin.erenkrantz@gmail.com
 designates 64.233.184.236 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth;
        b=MP5JSsnIFML5ACsKxRIwuq12bIdadjFK/L3N6BJdrTZ9urPQEDZiNigGBX5UJBmjxunhZMEzZtJMIK6iKf1ntWwiyxETa1yNov04FhgSoz4FVvqxAbBJw8Vcuj/Ty+g+H7l53ypiICqmtgOBd2o8VsmItGPBI7xvpUMR7rp7dfM=
Message-ID: <5c902b9e0610300851j551ed5fex6d1508d359403ecd@mail.gmail.com>
Date: Mon, 30 Oct 2006 09:51:30 -0700
From: "Justin Erenkrantz" <justin@erenkrantz.com>
Sender: justin.erenkrantz@gmail.com
To: dev@httpd.apache.org
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
In-Reply-To: <4545BA36.4040501@beamartyr.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <20061027132858.5098B1A9846@eris.apache.org>
	 <20061029232321.GC2515@scotch.ics.uci.edu> <45453EEE.9090308@sharp.fm>
	 <5c902b9e0610292158q64a48770l3f69f0f1c60b506a@mail.gmail.com>
	 <4545B260.50604@beamartyr.net>
	 <5c902b9e0610300009k87c0befjd989972cbf821ceb@mail.gmail.com>
	 <4545BA36.4040501@beamartyr.net>

On 10/30/06, Issac Goldstand <margol@beamartyr.net> 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