Re: svn commit: r642558 - in /httpd/httpd/trunk: CHANGES NWGNUmakefile build/nw_export.inc include/ap_expr.h include/ap_mmn.h libhttpd.dsp server/Makefile.in server/util_expr.c

2008-03-31 Thread Nick Kew
On Sun, 30 Mar 2008 16:36:28 +0200 Ruediger Pluem <[EMAIL PROTECTED]> wrote: PARSE_STRING(r, > > current->left->token.value); > > +current->left->value > > = !!*current->left->token.value; > > Why do we use !! here? Isn't this the same as !! not being there? I don't un

Re: svn commit: r642558 - in /httpd/httpd/trunk: CHANGES NWGNUmakefile build/nw_export.inc include/ap_expr.h include/ap_mmn.h libhttpd.dsp server/Makefile.in server/util_expr.c

2008-03-31 Thread Jim Jagielski
On Mar 31, 2008, at 8:26 AM, Nick Kew wrote: On Sun, 30 Mar 2008 16:36:28 +0200 Ruediger Pluem <[EMAIL PROTECTED]> wrote: PARSE_STRING(r, current->left->token.value); +current->left->value = !!*current->left->token.value; Why do we use !! here? Isn't this the same a

Re: svn commit: r642558 - in /httpd/httpd/trunk: CHANGES NWGNUmakefile build/nw_export.inc include/ap_expr.h include/ap_mmn.h libhttpd.dsp server/Makefile.in server/util_expr.c

2008-03-31 Thread Plüm , Rüdiger , VF-Group
> -Ursprüngliche Nachricht- > Von: Jim Jagielski > Gesendet: Montag, 31. März 2008 16:10 > An: dev@httpd.apache.org > Betreff: Re: svn commit: r642558 - in /httpd/httpd/trunk: > CHANGES NWGNUmakefile build/nw_export.inc include/ap_expr.h > include/ap_mmn.h libhttpd.dsp server/Makefile

Re: Dynamic configuration for the hackathon?

2008-03-31 Thread Paul Querna
Akins, Brian wrote: On 3/26/08 9:06 AM, "Nick Kew" <[EMAIL PROTECTED]> wrote: There seems to be a demand for dynamic per-request configuration, as evidenced by the number of users hacking it with mod_rewrite, and the other very limited tools available. Modern mod_rewrite usage commonly looks l

Re: Dynamic configuration for the hackathon?

2008-03-31 Thread Paul Querna
Nick Kew wrote: On Thu, 27 Mar 2008 08:17:01 -0400 "Akins, Brian" <[EMAIL PROTECTED]> wrote: On 3/27/08 3:58 AM, "Torsten Foertsch" <[EMAIL PROTECTED]> wrote: So I was going to reimplement it based on mod_wombat some time this year. The nice thing about lua, in addition to being lightweigh

Re: Dynamic configuration for the hackathon?

2008-03-31 Thread Issac Goldstand
Paul Querna wrote: Akins, Brian wrote: On 3/26/08 9:06 AM, "Nick Kew" <[EMAIL PROTECTED]> wrote: There seems to be a demand for dynamic per-request configuration, as evidenced by the number of users hacking it with mod_rewrite, and the other very limited tools available. Modern mod_rewrite u

Re: Dynamic configuration for the hackathon?

2008-03-31 Thread Akins, Brian
On 3/31/08 1:46 PM, "Issac Goldstand" <[EMAIL PROTECTED]> wrote: > if possible (to > remove completely unnecessary bloating) Lua != perl Lua < perl (size wise by an order of magnitude) > And in > addition, the learning curve to learn to use these powerful directives > is still optional I disa

Re: Dynamic configuration for the hackathon?

2008-03-31 Thread Akins, Brian
On 3/31/08 1:39 PM, "Paul Querna" <[EMAIL PROTECTED]> wrote: > We should just do it right, and stop hacking around the central problem. > > Expose the structures. > > Embed Lua. +1, but you already knew that... Also, mod_wombat, as such, goes away if Lua is embedded. We may have a module tha

Re: Dynamic configuration for the hackathon?

2008-03-31 Thread Paul Querna
Issac Goldstand wrote: Paul Querna wrote: Akins, Brian wrote: On 3/26/08 9:06 AM, "Nick Kew" <[EMAIL PROTECTED]> wrote: There seems to be a demand for dynamic per-request configuration, as evidenced by the number of users hacking it with mod_rewrite, and the other very limited tools availabl

Re: Dynamic configuration for the hackathon?

2008-03-31 Thread Issac Goldstand
Paul Querna wrote: Issac Goldstand wrote: I think the right approach is to first change the internal configuration API. Make it a real API, not a series of callbacks with filepointers and strings in them. Once we have that, we can write language bindings for all of them, and all langua

Re: Dynamic configuration for the hackathon?

2008-03-31 Thread Roy T. Fielding
On Mar 31, 2008, at 10:39 AM, Paul Querna wrote: Just read the mod_rewrite docs: http://httpd.apache.org/docs/2.2/rewrite/rewrite_tech.html#InternalAPI They are already exposing internals to "users'. "Users" want customization. We should just do it right, and stop hacking around the central

Re: svn commit: r642971 - in /httpd/httpd/trunk: include/ap_expr.h include/ap_mmn.h server/main.c server/util_expr.c

2008-03-31 Thread Ruediger Pluem
On 03/31/2008 02:17 PM, [EMAIL PROTECTED] wrote: Author: niq Date: Mon Mar 31 05:16:58 2008 New Revision: 642971 URL: http://svn.apache.org/viewvc?rev=642971&view=rev Log: Flesh out ap_expr with: * Re-usable parse trees * Canonical string parser function (candidate) Modified: httpd/http

Re: svn commit: r642971 - in /httpd/httpd/trunk: include/ap_expr.h include/ap_mmn.h server/main.c server/util_expr.c

2008-03-31 Thread Nick Kew
On Mon, 31 Mar 2008 22:24:50 +0200 Ruediger Pluem <[EMAIL PROTECTED]> wrote: > I don't like exposing internals to a public API. If the API user > always calls it with NULL we should hide this from the API users by > using a thin wrapper. Indeed, I think clone needs to be hidden altogether, and pl

Re: svn commit: r642971 - in /httpd/httpd/trunk: include/ap_expr.h include/ap_mmn.h server/main.c server/util_expr.c

2008-03-31 Thread André Malo
* Nick Kew wrote: > On Mon, 31 Mar 2008 22:24:50 +0200 > > Ruediger Pluem <[EMAIL PROTECTED]> wrote: > > > #define CREATE_NODE(pool,name) do { \ > > > -(name) = apr_palloc(pool, sizeof(*(name))); \ > > > -(name)->parent = (name)->left = (name)->right = NULL;

Re: svn commit: r642558 - in /httpd/httpd/trunk: CHANGES NWGNUmakefile build/nw_export.inc include/ap_expr.h include/ap_mmn.h libhttpd.dsp server/Makefile.in server/util_expr.c

2008-03-31 Thread William A. Rowe, Jr.
Nick Kew wrote: Why do we use !! here? Isn't this the same as !! not being there? !! is int -> bool (1 or 0 value). Why - that's a good question.

Re: Dynamic configuration for the hackathon?

2008-03-31 Thread William A. Rowe, Jr.
Issac Goldstand wrote: Paul Querna wrote: Akins, Brian wrote: On 3/26/08 9:06 AM, "Nick Kew" <[EMAIL PROTECTED]> wrote: There seems to be a demand for dynamic per-request configuration, as evidenced by the number of users hacking it with mod_rewrite, and the other very limited tools availabl

Re: Dynamic configuration for the hackathon?

2008-03-31 Thread Paul Querna
William A. Rowe, Jr. wrote: Issac Goldstand wrote: Paul Querna wrote: Akins, Brian wrote: On 3/26/08 9:06 AM, "Nick Kew" <[EMAIL PROTECTED]> wrote: There seems to be a demand for dynamic per-request configuration, as evidenced by the number of users hacking it with mod_rewrite, and the othe

Re: Dynamic configuration for the hackathon?

2008-03-31 Thread William A. Rowe, Jr.
Paul Querna wrote: Then the existing configuration file, a new lua system, or anything else, could be written in terms of that, rather than the current system where each language reinvents the modules it wants to control. I sympathize, but this doesn't reflect the addition of blocks... thos

Re: Dynamic configuration for the hackathon?

2008-03-31 Thread Issac Goldstand
Paul Querna wrote: William A. Rowe, Jr. wrote: Issac Goldstand wrote: Paul Querna wrote: Akins, Brian wrote: On 3/26/08 9:06 AM, "Nick Kew" <[EMAIL PROTECTED]> wrote: There seems to be a demand for dynamic per-request configuration, as evidenced by the number of users hacking it with mod_r

Re: Dynamic configuration for the hackathon?

2008-03-31 Thread Justin Erenkrantz
On Mon, Mar 31, 2008 at 11:15 AM, Roy T. Fielding <[EMAIL PROTECTED]> wrote: > Unfortunately, after last year's experience of being the only server > person around who wasn't working on a Joost release, *hides* > I decided to delay > my arrival until Tuesday rather than attend the hackathon.

Re: Dynamic configuration for the hackathon?

2008-03-31 Thread Justin Erenkrantz
On Mon, Mar 31, 2008 at 7:41 PM, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote: > I sympathize, but this doesn't reflect the addition of blocks... > those blocks can be trivially implemented as a loadable module ;-) As I grok it, the point would be throw out our ridiculous config syntax entire