httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Max Kellermann <...@duempel.org>
Subject Re: [PATCH] first snapshot of my "let's kill void*env" patch
Date Sun, 09 Jan 2005 23:27:15 GMT
On 2005/01/08 21:55, Max Kellermann <max@duempel.org> wrote:
> - review names: apreq_handle_t, null_module, constructor names
>   apreq_get_X()

Let's talk about this task ...

What is an "env"? Is it
- an env module (class)
- information an env module processes (instance), e.g. apr_pool_t and request_rec

In the current apreq, apreq_env_t is an env module, and void*env is
the env "instance". I would like to clarify that.

What about:
- apreq_env_t -> apreq_env_class_t
- void*env [apreq_handle_t in my patch] -> apreq_env_handle_t

.. and the variables of type apreq_handle_t are called "env" (instead
of "handle" in my first patch). That would leave the variable name
"env" consistently where it is now; apreq_env_class_t should be hidden
inside apreq anyway, visible only to the core and to the env classes
itself.

Should the cgi env class move to env/ ? Sounds evident to me, but it
should be linked into libapreq.so, is that ok? Or is the env/
directory only for "external" env modules like mod_apreq?

This is not an issue in perl, perl needs no distinction between a
"class type" and an "instance type".

another name to discuss: "null_module" - "null" is not a good name
choice. maybe "custom_module"?

Max


Mime
View raw message