Re: mod_comment (was: svn commit: r106879 ...)

2004-11-30 Thread Rici Lake
On 29-Nov-04, at 11:02 AM, William A. Rowe, Jr. wrote: 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)... Sorry, I don't understand that. The search for is in the first line of the directive; arg

mod_comment (was: svn commit: r106879 ...)

2004-11-29 Thread Greg Stein
On Mon, Nov 29, 2004 at 09:44:14AM -0500, Rici Lake wrote: ... Just out of curiousity, what do people think is wrong with the Comment directive implemented by this micro-module: https://ssl.bulix.org/projects/rici/file/apache/mod_comment.c?rev=49 That module uses a feature of the

Re: mod_comment (was: svn commit: r106879 ...)

2004-11-29 Thread Rici Lake
On 29-Nov-04, at 10:10 AM, Greg Stein wrote: So no... I don't like mod_comment. It uses a feature that I dearly wish to see removed from httpd. I agree 100% on removing that feature. If it were gone, something like mod_comment would have to be implemented in the core, I suppose. However, I was not

Re: mod_comment (was: svn commit: r106879 ...)

2004-11-29 Thread André Malo
* Greg Stein [EMAIL PROTECTED] wrote: https://ssl.bulix.org/projects/rici/file/apache/mod_comment.c?rev=49 That module uses a feature of the configuration parser that should be removed. The capability of code external to the config parser taking over the reading/parsing of the config file

Re: mod_comment (was: svn commit: r106879 ...)

2004-11-29 Thread Greg Stein
On Mon, Nov 29, 2004 at 04:20:21PM +0100, Andr? Malo wrote: * Greg Stein [EMAIL PROTECTED] wrote: https://ssl.bulix.org/projects/rici/file/apache/mod_comment.c?rev=49 That module uses a feature of the configuration parser that should be removed. The capability of code external to the

Re: mod_comment (was: svn commit: r106879 ...)

2004-11-29 Thread André Malo
* Greg Stein [EMAIL PROTECTED] 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

Re: mod_comment (was: svn commit: r106879 ...)

2004-11-29 Thread William A. Rowe, Jr.
At 09:31 AM 11/29/2004, André Malo wrote: * Greg Stein [EMAIL PROTECTED] 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

Re: mod_comment (was: svn commit: r106879 ...)

2004-11-29 Thread André Malo
* William A. Rowe, Jr. [EMAIL PROTECTED] wrote: This is the offending code; endp = ap_strrchr_c(arg, ''); if (endp == NULL) { return unclosed_directive(cmd); } Aah! understood, thanks ;-) So I'd guess, there's currently no good way for implementing containers? nd

Re: mod_comment (was: svn commit: r106879 ...)

2004-11-29 Thread Greg Stein
On Mon, Nov 29, 2004 at 07:33:35PM +0100, Andr? Malo wrote: * William A. Rowe, Jr. [EMAIL PROTECTED] wrote: This is the offending code; endp = ap_strrchr_c(arg, ''); if (endp == NULL) { return unclosed_directive(cmd); } Aah! understood, thanks ;-) So I'd

Re: mod_comment (was: svn commit: r106879 ...)

2004-11-29 Thread Justin Erenkrantz
--On Monday, November 29, 2004 10:41 AM -0800 Greg Stein [EMAIL PROTECTED] wrote: but we were not allowed to remove features. Removing the fp from the API would have disabled this feature in mod_perl, among others. I can't tell you how often I've been bitten personally by mod_perl trying to