Mailing-List: contact apreq-dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (hermes.apache.org: local policy)
Date: Wed, 26 Jan 2005 09:20:26 +0100
From: Max Kellermann <max@duempel.org>
To: apreq-dev@httpd.apache.org
Subject: Re: [multi-env] privatizing apreq_request_t and apreq_jar_t
Message-ID: <20050126082026.GB2127@roonstrasse.net>
References: <20050112221409.GA20209@roonstrasse.net>
 <876520kmfq.fsf@gemini.sunstarsys.com> <87d5vsc20f.fsf@gemini.sunstarsys.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87d5vsc20f.fsf@gemini.sunstarsys.com>
User-Agent: Mutt/1.5.6+20040907i

On 2005/01/26 04:17, Joe Schaefer <joe+gmane@sunstarsys.com> wrote:
> Now let's try to remove apreq_request_t and apreq_jar_t from the
> multi-env branch.  My basic idea is to remove those public structs,
> and to replace the current apreq_env_module_t accessors
[...]

looks like a good idea to me. This would also allow us to get rid of
apreq_strtoval. For practical reasons, I'd rename "apreq_env_handle_t"
to something simpler, maybe even "apreq_t"?

> The downside is that some Apache::Request users will still 
> want to modify those tables (not just fields within the 
> individual table entries), so we might need to include 
> the missing add|set|delete table operations for each 
> (jar,args,body. Otherwise we let each env module decide 
> to support (or not) the missing functionality through its 
> own API.

Why would they want? Just backwards compatibility?

Maybe we should implement that in the perl glue then, without having
to modify the C API?

I'd prefer not to bloat the env API.

Max