httpd-test/perl-framework STATUS: -*-text-*-
Last modified at [$Date: 2002/03/09 05:22:48 $]
Stuff to do:
* finish the t/TEST exit code issue (ORed with 0x2C if
framework failed)
* change existing tests that frob the DocumentRoot (e.g.,
William A. Rowe, Jr. wrote:
At 02:18 PM 11/10/2003, you wrote:
Bill Stoddard wrote:
[...]
Any ideas how to avoid the second call to initalize_module when I run as a service ?
You can't avoid the second call but there are ways to gracefully handle it. Here is a snip of code from a module I
MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote:
Disclaimer : Not targetting any one individual
I don't think there is target here, i consider it more as an open
discussion.
I have a question to the people have lots of time to write such long mails
and responses - why can't you instead spend
Jeff Trawick wrote:
[...]
Since the work arounds (such as Bill suggested) are required for 1.3
and 2.0
compatiblity already, it seems we should focus on 2.1 and solve this
for good.
as far putting a solution in 2.0, what is it our concern if a module
wants to support only Apache = 2.0.50?
On Nov 13, 2003, at 2:43 PM, Jeff Trawick wrote:
ap_mpm_query(), implemented by each MPM, would need some help from
core to determine which pass of the pre/post-config hook it is, since
that is out of the MPM's domain.
It seems to me that the proposed patch (for modules) elegantly solves
a
Jim Jagielski wrote:
On Nov 13, 2003, at 2:43 PM, Jeff Trawick wrote:
ap_mpm_query(), implemented by each MPM, would need some help from
core to determine which pass of the pre/post-config hook it is, since
that is out of the MPM's domain.
It seems to me that the proposed patch (for modules)
-Original Message-
From: Matthieu Estrade [mailto:[EMAIL PROTECTED]
[SNIP]
But when you give feedback, review code, and post patch and nothing
happen then... It's not easy to continue this way =)
Maybe my feedback and mails aren't good, so in this case i understand
more... but with no
In a message dated 11/13/2003 12:53:42 PM Central Standard Time, [EMAIL PROTECTED] writes:
By the by...
Covalent signs my paycheck.
And if you look at 1.3, you'll see that I've been pretty
key on staying on top of it.
Kind of blows away your theory, don't it?
Nope
At 12:47 PM 11/13/2003, [EMAIL PROTECTED] wrote:
If you look at what has REALLY happened in the past
3 years ( yes... going back that far since it's now 4 or
5 years since 2.0 became a real blib on the radar ) there's
no question that there was this intense period of
development and 'new' things
Hi Bill...
This is Kevin...
William Rowe wrote...
We value individual contributions here, not
corporate affiliation.
We means ASF, right?
If so... then I think you just nailed the whole point
of this thread, if I am reading the original poster's
concerns correctly.
There doesn't CURRENTLY
Mads Toftum wrote:
On Wed, Nov 12, 2003 at 05:10:24PM -0800, Aaron Bannert wrote:
My main requirement is that the bug tracking system be fully-accessible
through email. Having a full web interface is great, but not at the
expense of usable offline replies to bug reports.
RT could be what you're
* Ace Suares [EMAIL PROTECTED] wrote:
Sure. But no one reacted on the mod_auth_ldap problem for over 3 days !
Jeez you must be real busy !
Exactly. Believe it or not.
nd
My reading of RFC 2616 is that Accept-encoding is only for
content-codings.
You are right. Brain fart on my part.
I am still not sure how the discussion about mod_deflate
has gotten anywhere near Transfer-Encoding:.
mod_deflate is NOT DOING TRANSFER ENCODING.
Was it you that suggested it was
Justin Erenkrantz wrote:
On Tue, Nov 04, 2003 at 01:41:46AM -0800, Stas Bekman wrote:
filter. What happens if the filter returns less bytes (while there is still
more data coming?) What happens if the filter returns more bytes than
requested (e.g. because it uncompressed some data). After all
--On Thursday, November 13, 2003 12:38 AM -0800 Stas Bekman [EMAIL PROTECTED]
wrote:
Great. Where this should be documented? In the ap_get_brigade .h?
It's already in util_filters.h. Read the documentation for ap_input_mode_t:
/** The filter should return at most readbytes data. */
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
* Ace Suares [EMAIL PROTECTED] wrote:
Sure. But no one reacted on the mod_auth_ldap problem for over 3 days !
Jeez you must be real busy !
Exactly. Believe it or not.
I believe it. Just saw the [STATUS] messages.
But one simple question,
* Ace Suares [EMAIL PROTECTED] wrote:
But one simple question, 'is this the right list for mod_auth_ldap, and do
you know who is 'responsible' for it, don't get answered, however, there
is time to answer about a broken threading and even time to answer that
you're real busy... way to go.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Sure it is the right list.
Thx!
Unfortunately I can't help you in this case,
because my ldap knowledge is about zero.
My C skills are zero. I see just the two of us won't get anywhere ;-)
However, one tip: Don't give up.
Repeat your
Ace Suares wrote:
Brent Putnam has told me that mod_auth_ldap in 2.0 differs from 1.3 (the
external rudedog module) and that his patch won't work, and that he has no
time on his hands at the moment. Okay, that means that as only option I can
just post a bug report, and I will... In the hope
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Graham,
The wheels turn slowly, but they do turn.
grin...
If you expect people to be at
your beck and call, to apply the patches immediately as they're
submitted, then you're going to have to pay us :)
I don't expect that! But hey, if you
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi All,
I posted a bug report at
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24683
If you have firther questions, I will be available.
Cheers,
ace
website: http://www.suares.nl * http://www.qwikzite.nl
-BEGIN PGP SIGNATURE-
I've quite a few ideas and opinions about why things might be quiet
these days. I'd recommend against taking any of these ideas too
seriously. Here is an idea: we have gotten out in front of the users.
Products have features and overtime they get more and more features.
Users have some
Aaron Bannert wrote:
On Tue, Nov 11, 2003 at 09:55:24AM -0700, Brad Nicholes wrote:
Just to point out the obvious fact that hopefully everybody can agree with and
consider taking action on: More code review[er]s would be useful regardless of
C-T-R vs. R-T-C. And whether or not you agree with
Good response - ask the customer what he wants and then help him achieve it.
It all starts with stability - compatibility - performance. The ASF has a
tough job ahead of it, getting millions of users to change.
Not an easy task in today's environment
Peter
-Original Message-
From: Ben
On Nov 12, 2003, at 8:51 PM, Justin Erenkrantz wrote:
I think our changes that we already have in the tree is about 'right'
for 2.2 (no big architecture changes, but lots of modules have been
rewritten and improved). It's just that no one has time or desire to
shepherd 2.2 to a release. And,
Jim Jagielski wrote:
Brad Nicholes wrote:
Also, this exposes a bug, I think, in 2.0/2.1.
parsed_uri.port is valid iff parsed_uri.port_str != NULL.
Currently, we are testing just to see if parsed_uri.port
itself isn't 0.
What you are saying then is that without testing parsed_uri.port_str,
there
Hi all...
I just have to jump in here since the topic is fascinating...
...and I think there's an opportunity here to review something
that has contributed to the 'slow down' at httpd-dev which
no one has seemed to grasp (yet).
I will call it... The Covalent Factor.
If you look at what has
On Thu, Nov 13, 2003 at 10:29:55AM -0500, Jim Jagielski wrote:
Another point to consider... With 2.2, module writers will need to
worry about *3* versions of Apache. Commercial entities which
have *just* gotten around to porting their 1.3 modules for 2.0
will likely not bother with 2.2 modules
Justin Erenkrantz wrote:
Well, 2.2 modules for the most part should be source-compatible with
2.0. Certain subsystems have changed dramatically (auth being the prime
example I can think of), but I wouldn't expect every module to have to
change to support 2.2. (This is, again, taking my
Justin Erenkrantz wrote:
--On Thursday, November 13, 2003 12:38 AM -0800 Stas Bekman
[EMAIL PROTECTED] wrote:
Great. Where this should be documented? In the ap_get_brigade .h?
It's already in util_filters.h. Read the documentation for
ap_input_mode_t:
/** The filter should return at most
Jeff Trawick wrote:
is there some bad or unhelpful behavior in apr_uri_parse() that should be
changed? (i.e., don't let port be non-zero if port_str is NULL)
Well, it's *documented* that port is only valid if port_str != NULL.
I see no reason why we need to change the code, when the method
Hi,
I would like to speak a little about all this slow answer or review
problems.
i will take example of my last patch about ldap-cache.
I started doing it 5 month ago, and posted few patch many times on [EMAIL PROTECTED]
Nobody answered on the list, i posted about 4 or 5 times the same
Matthieu Estrade wrote:
Then, Jeff Trawick get it and it become faster, lots of mail and
communication, and finally, the patch was commited last week.
Yep... finding a champion of your code/patch/fix in the
development team tends to result in quicker results. And
no, it shouldn't have to
Disclaimer : Not targetting any one individual
I have a question to the people have lots of time to write such long mails
and responses - why can't you instead spend that time to review patches and
give feedback ?
It sure will improve the life of httpd-dev.
Thanks
-Madhu
-Original
34 matches
Mail list logo
