httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject Re: mod_comment (was: svn commit: r106879 ...)
Date Mon, 29 Nov 2004 16:02:51 GMT
At 09:31 AM 11/29/2004, André Malo wrote:
>* Greg Stein <> wrote:
>> Taking over the reading/parsing of the file pointer. We pass the fp to
>> modules (when they process a directive), allowing them to read from
>> it. Bad bad bad. Especially when you're trying to read your config
>> from some place funky.
>I seem to miss something ;-). AFAICS the module just uses our API? (assuming
>you mean the things happening in ap_soak_end_container).

Yes, but our API dictates that they are looking for ...>
(in the case of this module) - which is a bad thing IMHO (and in
Greg's and Ryan's as well)...

This is the offending code;

    endp = ap_strrchr_c(arg, '>');
    if (endp == NULL) {
        return unclosed_directive(cmd);

and this is the good code;

    *(ap_directive_t **)dummy = NULL;
    return ap_soak_end_container(cmd, "<Comment");

(sort of)...

The problem is, I doubt this module inserts its contents into
the config tree.  So if we spew the contents (using mod_info,
or any other tool based on our config tree API) we lose the
contents.  (We had an earlier discussion on list which went
into whether or not we wanted to waste the ram on comments,
and the concensus was, at some point add a flag to the parser
to either include or discard comments from the tree.)

The hope was to allow multiple .conf file syntaxes, such that
we could insert an xml based format some day.  mod_perl, and
to a lesser degree, mod_macro, make this impossible.

Config parsing is a one (or two or three) pass operation at
server startup, we should take liberties with the cpu cycles 
to achieve an effective result.


View raw message