----- Original Message ----
> From: Eli Marmor <mar...@netmask.it>
> To: apreq-dev@httpd.apache.org
> Sent: Friday, March 6, 2009 10:12:44 AM
> Subject: Re: [RELEASE CANDIDATE] libapreq2 2.12 RC1
>
> Hi Joe,
>
> I think that I discussed the following issue with Issac, two years ago.
> Actually, the idea to have an interactive fallback for CGI, was mine,
> I was the "sponsor", and Issac programmed it (very well!).
>
> Before getting any decision, I want to discuss it again with him, which
> can't be done before Sunday:
That's fine, but realize that there are other committers on this project
whose votes towards a release count just as much as Issac's. If we get
majority consensus on the candidate I cut, I intend to release it, with
or without your's or Issac's approval.
> Currently, is_interactive_mode() is based on GATEWAY_INTERFACE, which
> is defined by any CGI query from the webserver (RFC). The second case
> is when a user runs it manually, so GATEWAY_INTERFACE is undefined, and
> the fallback is to get the params interactively. But there is a third
> case - When the user wants to feed QUERY_STRING manually. So if we test
> QUERY_STRING (rather than GATEWAY_INTERFACE), we support all the three
> cases, because QUERY_STRING is defined by any CGI query (even in POST -
> but with an empty content).
>
> I think this is going to be the first stable version with interactive
> mode, so it's the last opportunity to change this behavior. I want to
> re-check it.
The folks who participate in this project have a terrible habit of waiting
until a release candidate is cut before actually waking up, thinking about
the consequences, and hollering bloody murder just because things don't
"look perfect" on their favorite platform. I'm not saying we should lower
our standards, but I am saying waiting to test drive apreq until it's
release time is far too late in the game to be useful to us as a development
community (and is why I continue to cut Release Candidates instead of final
tarballs).
With respect to the CGI interactive mode, the fact that we are even adding
that into the cgi module itself means that we don't mind changing the behavior
of that module within minor version bumps. Therefore changing it again
after 2.12 is released is both realistic and likely to happen once we get
some usage feedback on it. I'm not worried about getting it perfect the
first time out of the gate, and I don't think any of the other committers
on this project are either.
YMMV.
