httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <joe+gm...@sunstarsys.com>
Subject [multi-env] privatizing apreq_request_t and apreq_jar_t
Date Wed, 26 Jan 2005 03:17:36 GMT
Joe Schaefer <joe+gmane@sunstarsys.com> writes:

> Max Kellermann <max@duempel.org> writes:
>
> [...]
>
>> - remove the second parameter from apreq_request() and apreq_cookie()
>
> Actually, where I see the handle/module concepts 
> heading is to the privatization of apreq_jar_t and 
> apreq_request_t.


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

-   apreq_jar_t *(*jar)(apreq_env_handle_t *, apreq_jar_t *);
-   apreq_request_t *(*request)(apreq_env_handle_t *, apreq_request_t *);

with something simple:

+   apr_status_t (*jar)(apreq_env_handle_t *, const apr_table_t **);
+   apr_status_t (*args)(apreq_env_handle_t *, const apr_table_t **);
+   apr_status_t (*body)(apreq_env_handle_t *, const apr_table_t **);
+
+   apreq_cookie_t *(*cookie)(apreq_env_handle_t *, const char *);
+   apreq_param_t *(*query_param)(apreq_env_handle_t *, const char *);
+   apreq_param_t *(*body_param)(apreq_env_handle_t *, const char *);


The upside is that we only expose a const apr_table_t now, 
so libapreq2 users can't do any unsafe operations on that.
And we still maintain the "get-all" vs. "get-first" 
semantics on the body params, so lazy parsing works ok.

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.

Any thoughts on this?

-- 
Joe Schaefer


Mime
View raw message