Looking at nd's recent mod_rewrite and mod_include changes including the aaa
rewrite (and some other changes and new modules that just weren't backported),
I'm starting to think this is about the 'right feel' for a 2.2 release. 2.1
has essentially been open since last September.
So, I think we
On Sun, 31 Aug 2003, Justin Erenkrantz wrote:
> Looking at nd's recent mod_rewrite and mod_include changes including the
> aaa rewrite (and some other changes and new modules that just weren't
> backported), I'm starting to think this is about the 'right feel' for a
> 2.2 release. 2.1 has essenti
> From: Justin Erenkrantz [mailto:[EMAIL PROTECTED]
> Sent: Sunday, August 31, 2003 6:48 PM
> Looking at nd's recent mod_rewrite and mod_include changes including the aaa
> rewrite (and some other changes and new modules that just weren't backported),
> I'm starting to think this is about the 'r
On 31/08/2003, at 09:21, Sander Striker wrote:
Indeed. Since 2.2 is already about the AAA rewrite it would be nice
to include
the final step on that subject aswell.
Thoughts? -- justin
What about: I'll do a 2.1 release at the same time as 2.0.48?
Just to prevent any misunderstandings: are we t
On Sun, 31 Aug 2003, Erik Abele wrote:
> Just to prevent any misunderstandings: are we talking about a 2.2
> *alpha* or *beta* release here, or what will it be called? If it's in
> any way marked as *unstable*, then a clear +1 from my side. The recent
> changes are definitely worth to get tested i
Seems like a plan.
Do we then migrate from 2.0 to 2.2 for our *stable* tree? Some extra
clarification might be nice...
david
- Original Message -
From: "Justin Erenkrantz" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, August 31, 2003 5:48 PM
>> Just to prevent any misunderstandings: are we talking about a 2.2
>> *alpha* or *beta* release here, or what will it be called? If it's in
>> any way marked as *unstable*, then a clear +1 from my side. The recent
>> changes are definitely worth to get tested in the wild, IMHO.
> The alphas/beta
David Reid wrote:
> Seems like a plan.
>
> Do we then migrate from 2.0 to 2.2 for our *stable* tree? Some extra
> clarification might be nice...
Well, as Cliff pointed out, we would start issuing releases under the 2.1
moniker. Then, when we're all feeling warm and fuzzy about 2.1, we'll
call it
Well, as Cliff pointed out, we would start issuing releases under the 2.1
moniker. Then, when we're all feeling warm and fuzzy about 2.1, we'll
call it 2.2, and open APACHE_2_2_BRANCH. HEAD would then become 2.3.
APACHE_2_0_BRANCH would still be open.
Before 2.2 is even considered shouldn't all
--On Tuesday, September 02, 2003 13:40:23 -0700 Stas Bekman
<[EMAIL PROTECTED]> wrote:
Before 2.2 is even considered shouldn't all the outstanding design issues
be fixed first? e.g. there are at least several design problems with
filters.
Aren't you just talking about the fact that it's not a dou
Justin Erenkrantz wrote:
--On Tuesday, September 02, 2003 13:40:23 -0700 Stas Bekman
<[EMAIL PROTECTED]> wrote:
Before 2.2 is even considered shouldn't all the outstanding design issues
be fixed first? e.g. there are at least several design problems with
filters.
Aren't you just talking about t
Another problem with filters design is the init_filter function. I
forgot the details, I hope Geoff can give them, as he has messed with it.
the issue is primarily with default_handler.
for instance, there is currently a bug in the interaction between
mod_include and default_handler: if default
--On Wednesday, September 3, 2003 3:33 PM -0400 Geoffrey Young
<[EMAIL PROTECTED]> wrote:
other issues that I have found center around 304s. I can go into more
detail here if people like, but the overall idea is that filter_init is
sometimes too early to make intelligent decisions, especially wh
I, for one, would appreciate more details to better understand the
needs. I'm not clear where the mime type fits in.
well, say you have an output filter that should only operate on a particular
mime-type - like the mod_blanks that keeps coming up here. ideally, the
filter should be able to
I recall some discussion that the walk-through-every-registered-hook-provider
to resolve the handler is a pretty slowish/crufty way to handle that part of
the request processing. Especially if everyone sets up the handler up-front
in the various request preprocessing phases.
The problem with leav
* William A. Rowe, Jr. wrote:
> So perhaps it's time to deprecate req_rec::handler in favor of a handler_fn
> or some other sort of hash, and make the handler phase 1:1 on the request?
That sounds like a very good idea to me.
But how would you handle things like "handler1 returns DECLINED and han
William A. Rowe, Jr. wrote:
I recall some discussion that the walk-through-every-registered-hook-provider
to resolve the handler is a pretty slowish/crufty way to handle that part of
the request processing. Especially if everyone sets up the handler up-front
in the various request preprocessing ph
17 matches
Mail list logo
