date:20031113

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 developed a while back:
[...]
and I posted a patch which provides a generic API to do that. Since everybody is
replicating this code. And the thread has died w/o resolution. For some reason
http://marc.theaimsgroup.com doesn't have my original post, but only the rest of the
(unfinished) thread.

Stas,

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? we may have our own modules that need such an
API enhancement

We have a new facility, ap_mpm_query, which would be perfect for answering
nuggets of wisdom such as;
* Running as a win32 service? Or detached console daemon?
* A parent process? (Pre-fork or never forking (e.g. win32?)
* Pre-startup config testing?
* Server generation? (This answers the 2nd, 3rd, 4th startup pass question)
a check for is-terminating would be nice too... there's a nice mod_cgid
restart patch in 2.1-dev that needs a way to query whether the other child
checker got APR_OC_REASON_DEATH because the other child died on its own or
because it died because the server is terminating... right now the logic uses
ap_graceful_stop_signalled(), which is a dummy function with prefork... with
worker, ap_graceful_stop_signalled() works well enough for the mod_cgid patch,
but it doesn't distiguish between graceful and ungraceful termination

If we add AP_MPMQ_QUERY_STATE request that returns one of
{AP_MPMQ_STATE_INITIALIZED, AP_MPMQ_STATE_INITIALIZING,
AP_MPMQ_STATE_GRACEFUL_STOP, AP_MPMQ_STATE_HARD_STOP}, modules ought to be able
to get some type of clue on the big picture, though that doesn't help with
which pass of the pre/post-config hook it is.

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.

I must admit I don't understand the original initialize-module question and how
it relates to whether MPM is run with -X mode. Any clues? I can see plain as
day the pre-config/post-config issue in server/main.c:main(). Without that
understanding, I'm not sure what sort of info sharing is needed between core
and the MPM to allow module to know whether or not this is the last time a
certain hook will be called during [re-]initialization.

Re: the wheel of httpd-dev life is surely slowing down, solutions please

2003-11-13 Thread Matthieu Estrade

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 that time to review patches and
give feedback ?
 

it's 9pm here and i am still at work, i was just taking a little time to 
answer before quit.
i agree it's a long mail because english is not easy for me.
I try to give feedback about all happen in modules and experimental code 
in httpd 2.0
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 answer, it's hard to think something about my work.

It sure will improve the life of httpd-dev.

 

I am not sure continuing this way will improve much the life of httpd-dev.
And core team will receive more and more mail they will not be able to 
answer in a reasonnable time.
I don't think the problem is in reviewing and giving feedback, but how 
this is used and what will happen then...

Thanks
-Madhu
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 13, 2003 10:47 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: the wheel of httpd-dev life is surely slowing down,
solutions please


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 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 were happening at
a fast rate. As more and more developers got interested
in getting 2.0 cranked out the (limited) resources all
got eaten up in the 2.0 development cycle and 1.3
development virtually shut down. It was even 'officially'
shut down long before 2.0 was ready ( 1.3 officially went
into maintenance mode only ).

So now you had lots of legacy developers ( albeit... lots
of weekend-warriors, too, but WW's are the heartbeat
of Open Source ) who knew 1.3 very well but were now
totally put out to pasture. Very few of them 'came over'
to the 2.0 development. The majority of the developers
for 2.0 were the 'paid to play' kind that were either being
paid to directly work on Apache ( I'll get to the Covalent
factor in a second ) or,  at least, were being paid to
do something else but no one seemed to mind if they
sat there at their real jobs all day and did Apache
development. They might not admit to being directly
paid to work on Apache but when that's what you are
doing all day and still bringing home a paycheck then
that's exactly what that is.
The 'other' not-so-dedicated-but-certainly-interested 
developers felt 'shut out' of the 2.0 development cycle
because it was obvious a lot of it was taking place
'off line' and nothing was being documented so they
couldn't really get a good handle on what was going
on in order to make a contribution.

So they were mostly 'waiting in the wings' for a lot of
the 2.0 DESIGN level decisions and concepts to 
become clear so they could 'jump in'.

Well... we all know that it was a looong time before
some of the 2.0 design concepts became 'clear' enough
for a not-paid-to-work-on-apache person to 'jump in'.
There were basically only 2 big changes to Apache 2.0
versus 1.x.
1. MPM. Get out of the 'prefork' only 'go fork thyself' design model.

2. ( Came later ) Add some I/O filtering and get rid of BUFF.

Well, these are both fine goals to have but they are not for
the faint-of-heart ( or within the grasp of most weekend-warriors ).
That brings me to The Covalent Factor.

Is anyone going to deny that at a certain point in the 2.0
development cycle the PRIMARY driving force was a 
group of people that ALL worked for one company? ( Covalent ).

That's certainly the way it looked.

...and these guys were crankin'... I mean they were
MOTIVATED, because Covalent's entire corporate
life revolves around Apache and they were actually 
high level deals going on with Compaq ( and other
corporate entities? ) that all revolved around getting
Apache 2.0 out the door.

At one point one of the Covalent guys ( I believe it
was that Randy Bloom fellow? ) was pretty much the
ONLY person who had any idea how the new 'filtering'
was even SUPPOSED to work. It was quite some time
before he even finished thinking it through and it went
through (too?) many re-works to even keep a good
grasp on it.
I remember the feeling for MONTHS was something like...
let's just see what Covalent comes up with and let them
put their stamp of approval on it and then

Re: Apache calls initialize module twice

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?  we may have our own modules 
that need such an API enhancement
Yup, mod_perl 2.0 now requires 2.0.46 and will most likely shift that 
requirement up with time. We can make this an optional feature, available only 
when Apache has it.

  We have a new facility, ap_mpm_query, which would be perfect for 
answering
nuggets of wisdom such as;

  * Running as a win32 service?  Or detached console daemon?
  * A parent process?  (Pre-fork or never forking (e.g. win32?)
  * Pre-startup config testing?
  * Server generation?  (This answers the 2nd, 3rd, 4th startup pass 
question)


a check for is-terminating would be nice too...  there's a nice mod_cgid 
restart patch in 2.1-dev that needs a way to query whether the other 
child checker got APR_OC_REASON_DEATH because the other child died on 
its own or because it died because the server is terminating...  right 
now the logic uses ap_graceful_stop_signalled(), which is a dummy 
function with prefork... with worker, ap_graceful_stop_signalled() works 
well enough for the mod_cgid patch, but it doesn't distiguish between 
graceful and ungraceful termination

If we add AP_MPMQ_QUERY_STATE request that returns one of 
{AP_MPMQ_STATE_INITIALIZED, AP_MPMQ_STATE_INITIALIZING, 
AP_MPMQ_STATE_GRACEFUL_STOP, AP_MPMQ_STATE_HARD_STOP}, modules ought to 
be able to get some type of clue on the big picture, though that doesn't 
help with which pass of the pre/post-config hook it is.

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.

I must admit I don't understand the original initialize-module question 
and how it relates to whether MPM is run with -X mode.  Any clues?  I 
can see plain as day the pre-config/post-config issue in 
server/main.c:main().  Without that understanding, I'm not sure what 
sort of info sharing is needed between core and the MPM to allow module 
to know whether or not this is the last time a certain hook will be 
called during [re-]initialization.
There are two seemingly unrelated (ortogonal?) questions:

1. Are we parsing config for the first or the second time

2. Are we in one of the START|RESTART|GRACEFUL|STOP mode.

Only in the START mode a module needs to know whether its config hooks are run 
for the first time or the second. In the rest of the modes it's always run 
once (first time).

So depending on how you look it, the two can be related or not.

I think there should be two unrelated functions. One telling us whether we are 
in first/second time config parsing (and I've posted a core patch for this). 
The other telling us the operation mode (requires patching of all mpm 
implementations).

__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Re: Apache calls initialize module twice

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 problem that a significant percentage of modules have to worry
about. I don't see why folding this into ap_mpm_query() is desirable 
when
the fix already exists. I think you're saying the same thing...

Re: Apache calls initialize module twice

2003-11-13 Thread MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1)

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) elegantly solves
a problem that a significant percentage of modules have to worry
about. I don't see why folding this into ap_mpm_query() is desirable when
the fix already exists. I think you're saying the same thing...
yeah :)  I was feeling that there would not be a clean way to combine the two 
issues, but I was trying to make sense of such a combination since I thought 
wrowe was trying to pull both topics together :)

RE: the wheel of httpd-dev life is surely slowing down, solutions please


-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 answer, it's hard to think something about my work.


Exactly my point. When you post a patch, and somebody replies back with some
feedback, it's like a sense of satisfaction for me. Atleast, I know somebody
out there (perhaps not a person with commit access) is giving some
importance to my mail and replying back. Some times, I don't even care if
the patch gets committed - as long as somebody reviews it. The reason : I
need to know if I'm doing something wrong :).

Imagine sending mails OR posting patches and NOT getting any replies at all.
I've experienced that. The common answer you get is try and try again - and
one day the light will shine upon you. 
I've got that answer a lot of times (it's in the archives if you have the
patience to dig in).

The question was intended to those people who talk a lot, but neither post
patches NOR give reviews/feedback, but jump in with long mails only when
there's a debate going on.


And core team will receive more and more mail they will not be able to 
answer in a reasonnable time.

Why wait for the core team to answer the questions - why should others NOT
pick up the role of answering the questions ?

-Madhu
(guilty on my own point)

Re: the wheel of httpd-dev life is surely slowing down, solutions please

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

Re: the wheel of httpd-dev life is surely slowing down, solutions please

2003-11-13 Thread William A. Rowe, Jr.

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 were happening at
a fast rate. 

Without a doubt this period of development was abnormally intense
for any five year old open source project.  Good point.

As more and more developers got interested
in getting 2.0 cranked out the (limited) resources all
got eaten up in the 2.0 development cycle and 1.3
development virtually shut down. It was even 'officially'
shut down long before 2.0 was ready ( 1.3 officially went
into maintenance mode only ).

That's an interesting point.  Most of my early (independent) contributions,
about 600 dev hours worth, were entirely focused on making 1.3 work
under Win32.  And you are dead on, some of my work was accepted,
and on other points, I was asked hold on, that's a goal in 2.0.  There
was a little difference though, there really was very little 2.0 anything
at that time for me to point my efforts at.

So now you had lots of legacy developers ( albeit... lots
of weekend-warriors, too, but WW's are the heartbeat
of Open Source ) who knew 1.3 very well but were now
totally put out to pasture. 

Nay, they were gone long before I started using/working with/hacking
Apache in 2000.  Even mod_ssl and OpenSSL were put to bed.  The
old guard had moved on, and few folks paid much attention to the bug
queue.  Those that did were overwhelmed by some requests that just
wouldn't fit well into the architecture of 1.3.  Not to mention that 1.3's 
core was a twisted mess of platform quirks.  It still is, that's why it's
orphaned.  Hard on old timers, sure, but for newcomers the difference
between reading 1.3 and 2.0 is night and day.

Yes filters are difficult to grok, but the rest of the entire server is much
more simple to follow.

Perhaps some will be motivated to make filters, the most difficult 2.0
feature, a little easier to use or understand.  Justin already made some
progress on this front, and it continues to evolve.

The 'other' not-so-dedicated-but-certainly-interested 
developers felt 'shut out' of the 2.0 development cycle
because it was obvious a lot of it was taking place
'off line' and nothing was being documented so they
couldn't really get a good handle on what was going
on in order to make a contribution.

Hehe, of all of your silly perceptions in this note, I'm picking up on
this one for the benefit of newer list readers.  In the bad old days of the 
2.0 dev cycle, very little ever happened that wasn't tracked on the
mailing list.  Today, there is parallel activity on channels like #apr
(of irc.freenode.net), and your comment reinforces the point that not all
of that activity can be healthy for the wider community.  Unless it is
digested and explained to the readership of dev@ and in the maillist
archives for posterity and future explanation.

At one point one of the Covalent guys ( I believe it
was that Randy Bloom fellow? ) was pretty much the
ONLY person who had any idea how the new 'filtering'
was even SUPPOSED to work. It was quite some time
before he even finished thinking it through and it went
through (too?) many re-works to even keep a good
grasp on it.

Hehe, this ties into my point in the prior paragraph.  EVERYTHING on the
filters was nailed down on the list.  What happened?

Two camps had two different end goals.  They did not see eye to eye
on the design.  When it got to the point that there was no resolution 
to be found, I suggested that a face to face of everyone interested would
be terrific.  Note I was an independent, not paid for webserver apps but 
actually a database systems dude who liked playing with the web.  And
I was tired of waiting for the discussion to end (and sorta confused as were
most observers.)  About 20+ folks, five different firms, some independents,
some by phone, sat down to watch Ryan and Greg duke out the design
one bullet point at a time.  It was amazing, wish that someone had 
a brought a camcorder :-)

And what resulted was a design that satisfied *everyones* requirements.
Details and skeletons were posted to the list in realtime by some observers.

What do you call this?  An impromptu mini-hackathon.  And it worked
to move forward on a very difficult-to-follow concept.

My only real point here ( and the way all this relates to the
current thread ) is that maybe it's time to acknowledge that
what is happening now is what will always happen to a major
development project if you let too many of your eggs go into
the same 'corporate' basket.

I'm gonna just close with this observation - Apache was always driven
by two forces, academic and business.  By ISPs who needed a stable
platform.  By independent coders who earned a living doing systems.
By companies who needed a stable and trusted base platform.

And Guess What?  There is

Re: the wheel of httpd-dev life is surely slowing down, solutions please

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 seem to be much evidence that
what you just said is TRUE.

'Individual' attempts to contribute are getting IGNORED
and the last few words of this message thread's subject
line are just asking to hear from the powers that be
what they intend to do about that ( solutions please ? ).

Requiring people to post and re-post and re-post patches
until they are blue in the face and/or need to start
shouting from mountaintops ( or find a 'backdoor' or 'inside
track' into the 'real inner cirlce' like the last guy
finally did ) is no way to 'walk the walk' that you
just talked ( We value individual contributions ).

Prove it.

Make it EASY to contribute... not a nightmare.

I think that's all the guy is asking for.

( and before you come back with the standard Are YOU
willing to review patches, then? at least I'll be honest
and say there's NO WAY right now or for the forseeable
future. Unlike you... I am NOT paid to work on Apache and
I just don't have the time. Besides, I'm also about 100%
sure you don't want me reviewing patches for Apache.
Newcomers can go read some archived messages
if they are curious about the history there. )

 Nobody has ever gotten a 'pass' into the Apache
 HTTP Server for their employment or their employers
 efforts.

Methinks thou dost protest too much.

I never suggested any such thing.

I never came near saying that Covalent or any of it's
myriad Apache developers were getting 'free passes'
to anything. It still takes votes to do things at
Apache and even though there are times when the
vote count includes mostly Covalent people ( like when
Apache 2.0 was released too early ) there is always
the VETO as a safety catch. It was never exercised
because as far as anyone knows nothing un-toward
was going on.

Apache is stil a 'meritocracy'... but isn't that
part of what the guy who started this thread is
complaining about?

He tried for 4 months to even get a leg up on
the bottom rung of the 'meritocracy' and no one
gave a shit. I would say that's a short-circuit
to the whole scheme itself. The powers that be
stay the powers that be unless 'new' people are
being give the chance to show what THEY can do.

 The fact that folks, such as Brad and Madhu,
 are committers and PMC members is a result of their
 personal dedication to the project and that the project
 is proud to count them as members, regardless of current
 employment status.

Then that means there was a time when they first tried
to post a patch as well. What was their experience?
Good, bad, or ugly?

How did they get a 'leg up' in the meritocracy?

I'm not asking these questions for myself... It's no
mystery to me and I know exactly how it's done and
how many rungs there are on that ladder. I am asking
the questions on behalf of the original poster and
I think the answers might fill out the thread subject.

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 were happening at
a fast rate.

Without a doubt this period of development was abnormally
intense for any five year old open source project.
Good point.

...and let's hope anyone that's even paying attention to
this thread isn't expecting Apache development to always
be that way. Sometimes ( like now ) it just becomes
'dog work' and the flash and glitter is hard to find.

There have NEVER been enough warm bodies at Apache and
there never will be. I think the red flags have gone
up because it's starting to appear as if NO ONE is
answering the phone at all anymore. That's a problem.

As more and more developers got interested
in getting 2.0 cranked out the (limited) resources all
got eaten up in the 2.0 development cycle and 1.3
development virtually shut down. It was even 'officially'
shut down long before 2.0 was ready ( 1.3 officially went
into maintenance mode only ).

That's an interesting point.  Most of my early (independent)
contributions, about 600 dev hours worth, were entirely
focused on making 1.3 work under Win32.

I know.

From some of your other comments it might appear that
your memory is failing a bit, Bill, but you must remember me.

I had Apache running under Windows using the (free) Borland
compiler about 2 years before you appeared but the concern
about making Apache for Windows REAL and going to head to head
with Microsoft only cranked up after that Mindspring article
appeared and showed that IIS was beating the pants off of
pre-fork Apache and the UNIX boys got all pissed off.
That was the 2x4 that got the mule's attention.

My patches to compile Apache under Windows using

Re: the wheel of httpd-dev life is surely slowing down, solutions please

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 looking for - http://www.bestpractical.com/rt

An example is http://rt.cpan.org
Seconded. The perl project uses RT with a great success (http://rt.perl.org/)

__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Re: the wheel of httpd-dev life is surely slowing down, solutionsplease

2003-11-13 Thread Andr Malo

* 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

Re: mod_deflate and transfer / content encoding problem

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 or the original
fellow who started the thread?

Content-encoding: gzip
Transfer-encoding: chunked

Cannot be interpreted as 'using Transfer encoding'.

That would be...

Transfer-encoding: gzip, chunked.

Is someone saying that's what they are actually
SEEING coming out of Apache? God... I hope not.

Bug-city.

Clients should indicate their ability to handle
transfer-codings via TE.

Yep... except a Server may always ASSUME that a client
can handle Transfer-encoding if it says it's HTTP 1.1
compliant. There's no need for a TE header at all.

The only caveat is that you can only assume a TE
encoding/decodiing capability of chunked.

Anything other than 'chunked' has to be indicated
with a TE header... you are right.

Problem here is that what I said about 'not knowing'
is still sort of true... it just didn't come out right.

A Server still has no way of knowing if the original
requestor can handle TE, or not.

The TE header is a 'hop by hop' header.
Might have come from the original requestor, might not.
There's no way to know.

And that's OK... that's all that TE: was designed for.
It's all based on the NN ( Nearest Neighbor )
concept and is a property of the 'message', not the 'content'.
It's just part of that strange mixture of transport AND
presentation layer concepts that is modern day HTTP.

Even if it shows up ( very rare ) the TE header is actually
SUPPOSED to be 'removed' by the NN ( Nearest Neighbor )...

[snip - From RFC 2616]

13.5.1 End-to-end and Hop-by-hop Headers

   For the purpose of defining the behavior of caches and non-caching
   proxies, we divide HTTP headers into two categories:

  - End-to-end headers, which are  transmitted to the ultimate
recipient of a request or response. End-to-end headers in
responses MUST be stored as part of a cache entry and MUST be
transmitted in any response formed from a cache entry.

  - Hop-by-hop headers, which are meaningful only for a single
transport-level connection, and are not stored by caches or
forwarded by proxies.

   The following HTTP/1.1 headers are hop-by-hop headers:

  - Connection
  - Keep-Alive
  - Proxy-Authenticate
  - Proxy-Authorization
  - TE
  - Trailers
  - Transfer-Encoding
  - Upgrade

   All other headers defined by HTTP/1.1 are end-to-end headers.

[snip]

Hop-by-hop headers, which are meaningful only for a single
transport-level connection, and are not stored by caches or
forwarded by proxies.

The above is, of course, not what is really going 'out there'
in the real world but it's all hit or miss and you still
can't be sure what's being 'forwarded' and what isn't.

I have certainly seen inline proxies 'forwarding' hop-by-hop
headers and 'caches' storing them, as well.

It's a jungle out there. ROFL.

If a Server really wants to be sure compressed content
is being sent all the way along the response chain
( including that critical 'last mile' ) to the original
requestor then the only choice is still to just
use 'Content-Encoding'... even if there is no
static representation or the page is totally
dynamic and doesn't even exist until it's asked for.

ASIDE: Maybe that's where someone is getting
confused about TE versus CE? When HTTP was
designed the whole CONTENT concept was
based on disk files and file extensions and
MIME types and whatnot but that's not how
things have evolved. Content-type is now
more a 'concept' than a physical reality.
There are gigabytes of Content these days
that doesn' even exist until someone asks
for it and it's NEVER represented on disk at all.

There's just no way to know if your 'last mile'
is covered with TE capability, or not.

The alternative to using the Content-encoding:
voodoo to get compressed representations of
non-compressed resources all the way down to a
client would be to have some sort of 'end-to-end'
TE header which says 'the content was compressed
because the original requestor says he wants it
that way so just pass it through'... but that
ain't gonna happen anytime soon.

Content-Encoding: gzip
together with
Transfer-Encoding: chunked

or simply...

Transfer-Encoding: gzip, chunked.

It should make no difference to the 'receiver'.


Well, not if the receiver is a caching proxy...

Personally... I still don't think that matters
much. I am of the opinion that it's always
'cheaper' to store compressed versions of
entities and then just decompress it if you
need to which means a proxy SHOULD just go ahead
and remove the chunking and stash the response
regardless of whether it came in as 'Content-encoded'
compression or 'Transfer-encoded' compression...
but that's just me.

Actually... I firmly believe any

Re: should input filter return the exact amount of bytes asked for?

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 the incoming 


Less bytes = OK.
Same bytes = OK.
More bytes = Not OK.  (Theoretically possible though with bad filters.)
Great. Where this should be documented? In the ap_get_brigade .h?

Also,

 0 bytes = Not OK

right? Or how otherwise would you explain the assertion:

  AP_DEBUG_ASSERT(!APR_BRIGADE_EMPTY(bb));

in consumers like ap_get_client_block. Or do you say that a filter can return 
a non-empty brigade with an empty single bucket?

Thanks Justin.

__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Re: should input filter return the exact amount of bytes asked for?

2003-11-13 Thread Justin Erenkrantz

--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. */
   AP_MODE_READBYTES,
   ...
right? Or how otherwise would you explain the assertion:

   AP_DEBUG_ASSERT(!APR_BRIGADE_EMPTY(bb));
If using APR_BLOCK_READ, it's illegal to return 0 bytes with AP_MODE_READBYTES 
- that is what this assert is checking for in maintainer mode (this was a 
troublesome assert at one point).  It's the same expectation as doing a 
blocking socking read() - blocking reads shouldn't return until something is 
returned.  -- justin

Re: the wheel of httpd-dev life is surely slowing down, solutionsplease

-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, '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. 

Okay, I am new here, and IANAD(Y), and I'll try to find out how to post the 
odd mod_auth_ldap behaviour as a bug and just hope the best for it. 

Cheer up! I am of the type that doesn't even *know* other webservers then 
apache. And I have great fun with the rewriting rules, oh yeah.

Bye,

ace




 nd

- -- 
Ace Suares' Internet Consultancy
NIEUW ADRES: Postbus 2599, 4800 CN Breda
telefoon: 06-244 33 608
fax en voicemail: 0848-707 705
website: http://www.suares.nl * http://www.qwikzite.nl
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)

iD8DBQE/s0zJy7boE8xtIjURAj3KAJ4sIOACkao26woUQ39n3sny2ijX6QCdHdZb
24kzGjkVEGMs714yJ1CLoOU=
=w/xM
-END PGP SIGNATURE-

Re: the wheel of httpd-dev life is surely slowing down, solutionsplease

2003-11-13 Thread Andr Malo

* 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. 

Hey ;-)

Sure it is the right list. Unfortunately I can't help you in this case,
because my ldap knowledge is about zero. However, one tip: Don't give up.
Repeat your questions every x days until someone replies. Otherwise people
even forget that they wanted to answer, because they are that busy. (It's my
experience with the folks here -- and myself as well :-).

nd

Re: the wheel of httpd-dev life is surely slowing down, solutionsplease

-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 questions every x days until someone replies. Otherwise people
 even forget that they wanted to answer, because they are that busy. (It's
 my experience with the folks here -- and myself as well :-).

I would never do that. Well, I'd never think of that. I reposted the question 
because it seemed to be in the wrong thread. And after three days... that's a 
looong time in internet, if no one replied after that it's never gonna be 
answered...

For mod_ldap, there is a listing on some webpage who's done something on that, 
I contacted [Graham] directly. But I couldn't find any name of the person who 
did mod_auth_ldap. That's why I poked my head around the door to ask 'who's 
there?'

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 that the next 2.0.x release 
will have it fixed. I mean, I downgraded from apache2 because of this 
problem! Only to discover it was there in 1.3 + rudedog too. But the rudedog 
module got fixed by Brent Putnam, but alas the maintainer of the rudedog 
module [Dave] hasn't reacted to my request to patch 1.6.0. 
So, there's a dead end there too... I love Open Source development :-)

I'd like to thank you for your answers and wish you (all) strength and courage 
in cranking out apache 2.0.x, 2.1.x, 2.2.x, 3, 4... for now I won't bother 
this list anymore ;-)

Cheers!
_Ace



website: http://www.suares.nl * http://www.qwikzite.nl
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)

iD8DBQE/s3Nmy7boE8xtIjURAqdXAJoCJVS5DN1/dWsofmQb5ZRdHAZ78gCeI7aG
7z78jpxJqkVCOR9HCLWzTPc=
=Lorr
-END PGP SIGNATURE-

Re: the wheel of httpd-dev life is surely slowing down, solutionsplease

2003-11-13 Thread Graham Leggett

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 that the next 2.0.x release 
will have it fixed. I mean, I downgraded from apache2 because of this 
problem! Only to discover it was there in 1.3 + rudedog too. But the rudedog 
module got fixed by Brent Putnam, but alas the maintainer of the rudedog 
module [Dave] hasn't reacted to my request to patch 1.6.0. 
So, there's a dead end there too... I love Open Source development :-)
The wheels turn slowly, but they do turn. 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 :)

The patch is available that in theory should solve your problem, so you 
should not have a need to downgrade from v2.0 - if the patch is in 
bugzilla then it won't fall through the cracks, and once I've achieved 
the impossible for my client by the end of this weekend, I'll have some 
time to review and apply it - you're going to have to be patient though.

Your effort in hunting down the problem in the first place is greatly 
appreciated - the end result is that Apache has one less bug and is mroe 
stable than before, but this stuff still takes time...

Regards,
Graham
--

Re: the wheel of httpd-dev life is surely slowing down, solutionsplease

-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 give me a quote on how much it'll cost, 
I'll consider ;-)


 The patch is available that in theory should solve your problem, so you
 should not have a need to downgrade from v2.0 - if the patch is in
 bugzilla then it won't fall through the cracks, and once I've achieved
 the impossible for my client by the end of this weekend, I'll have some
 time to review and apply it - you're going to have to be patient though.

I am patient - not so my client who wants the impossible before the end of 
this weekend and my hands are strained already from typing to much under 
pressure :-(
And, the patch for 2.0 is NOT there - Brent clearly stated to me that the 
newer module is different from the 1.6.0 rudedog module, and that his patch 
won't apply, and that he has no time to fix it now, but he'll look into it 
later. 

 Your effort in hunting down the problem in the first place is greatly
 appreciated - the end result is that Apache has one less bug and is mroe
 stable than before, but this stuff still takes time...

Brent did all the work - in 2001 ! No idea why it never made it to the 
rudedog module. If it had, it wouldn't be a bug in 2.0 !

I just wanted to talk to the right person. If that's you, then we are already 
in contact. I will NOW submit a bug report for 2.0 with the 1.3 patch 
attached, I think it's very easy for you to figure out how to patch 2.0, when 
the time is there. I am staying with 1.3 at least until the end of this 
weekend ;-)

Let the wheels turn - I am not in a hurry, my problem is already fixed.

Cheers,
ace

website: http://www.suares.nl * http://www.qwikzite.nl
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)

iD8DBQE/s4Uny7boE8xtIjURAo0+AKCQ/5i8MWo4ZaIIxo2KegID41B/NQCfQPK4
PoXxIdJ86V841l9QwdEi7Ck=
=PIH1
-END PGP SIGNATURE-

Re: Q: Intermittent trouble with mod_auth_ldap in 2.0 and 1.3

-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-
Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)

iD8DBQE/s4xWy7boE8xtIjURAiAMAJ9w6fngzK+dH6yJGgrGX40vJ+pEzQCfQG5k
jTWz9/Lm7BIqTz0QDosKLoI=
=x/U0
-END PGP SIGNATURE-

Re: the wheel of httpd-dev life is surely slowing down, solutions please

2003-11-13 Thread Ben Hyde

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 ability to absorb features and overtime their ability 
to do so rises.  For young products the users are ahead of the product 
(What do you mean it doesn't to CGI scripting!?).  For older products 
the mismatch gets smaller and smaller (I need massive virtual 
hosting!).

My joke about this is that the process is a perfect behaviorist 
training loop.  Young products get strong feedback which trains their 
sponsors to listen to customer demand and add features.  Overtime that 
feedback peter's out, which trains them to listen more and more 
carefully.  Finally they get to the point where they listen to the wind 
and they hear feature demands in it's ghostly moans.  That's call 
market research. :-)

Commercial products tend to overshoot the users.  Consider Microsoft's 
office products!

Open source is less given to overshoot.  If features only go in because 
a user volunteered to do the work that acts; to some degree to temper 
the chance of overshoot.

Open source can still overshoot.  Exceptional users may add features 
that are rarely needed.  Firms, lead by market research or other 
in-house demands, may volunteer.

So, one theory is that we have overshot the user's ability to absorb 
new features.  Some amount of overshoot is to be expected on any major 
release.

Solutions?  Well if you buy this model - and like I said it's only one 
- then the trick is to aid users in climbing the learning curve.  
Figuring out where the user demand is and then helping to bridge the 
gap using the new features.  Helping all the complementary products 
absorb the new stuff.

This may seem like an argument that we have filled out our ecological 
niche; but it's slightly different than that.  The niche isn't fixed, 
it is a free variable as well.

 - ben

Re: the wheel of httpd-dev life is surely slowing down, solutionsplease

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 the current order of 
Committing and Reviewing for the stable branch, helping out with reviews would 
result in fixes being merged into the stable branch much faster.

RE: the wheel of httpd-dev life is surely slowing down, solutions please

2003-11-13 Thread Peter J. Cranstone

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 Hyde [mailto:[EMAIL PROTECTED] 
Sent: Thursday, November 13, 2003 7:24 AM
To: [EMAIL PROTECTED]
Subject: Re: the wheel of httpd-dev life is surely slowing down, solutions
please

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 ability to absorb features and overtime their ability 
to do so rises.  For young products the users are ahead of the product 
(What do you mean it doesn't to CGI scripting!?).  For older products 
the mismatch gets smaller and smaller (I need massive virtual 
hosting!).

My joke about this is that the process is a perfect behaviorist 
training loop.  Young products get strong feedback which trains their 
sponsors to listen to customer demand and add features.  Overtime that 
feedback peter's out, which trains them to listen more and more 
carefully.  Finally they get to the point where they listen to the wind 
and they hear feature demands in it's ghostly moans.  That's call 
market research. :-)

Commercial products tend to overshoot the users.  Consider Microsoft's 
office products!

Open source is less given to overshoot.  If features only go in because 
a user volunteered to do the work that acts; to some degree to temper 
the chance of overshoot.

Open source can still overshoot.  Exceptional users may add features 
that are rarely needed.  Firms, lead by market research or other 
in-house demands, may volunteer.

So, one theory is that we have overshot the user's ability to absorb 
new features.  Some amount of overshoot is to be expected on any major 
release.

Solutions?  Well if you buy this model - and like I said it's only one 
- then the trick is to aid users in climbing the learning curve.  
Figuring out where the user demand is and then helping to bridge the 
gap using the new features.  Helping all the complementary products 
absorb the new stuff.

This may seem like an argument that we have filled out our ecological 
niche; but it's slightly different than that.  The niche isn't fixed, 
it is a free variable as well.

  - ben

Re: the wheel of httpd-dev life is surely slowing down, solutions please

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, I think we need APR 1.0 out the door 
before 2.2 can be rationally discussed.

If we did any major changes from this point that require modules to 
rewrite themselves, we'd need to go to 3.0 per our versioning rules.  
And, I'd *strongly* discourage that.  I don't think it's in anyone's 
best interest to revamp our architecture at this stage.

We don't need to give a moving target to our poor module developers.  
Only by producing a series of high-quality releases can we ensure that 
module writers will be confident in writing against 2.0 or 2.2.  If we 
come out with 3.x now, I think we'll just end up hurting ourselves in 
the long run even worse than we are now.  -- justin

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 for awhile.
There's no easy answer... Maybe dev on 2.0 is slow simply
because it's obvious that it's a dead end. Once 2.1
happened, there was a real concern in putting effort into
2.0 because the gravestone was already being carved for
it.
I do think that some sort of improved communication between
bugs and developers would be good. In general, once a developer
is aware of a bug and/or patch, things get done.

Re: [PATCH] UseCanonicalName (1.3/2.x)

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 is no way of knowing if port 0 could actually be a valid port or
if parsed_uri.port contains garbage that just happens to look like a
port.  The former depends on whether port 0 can actually be a valid port
and the latter depends on how the parsed_uri structure is initialized.


From what I can see (prelim look into the URI parsing) it is
possible for port to be garbage if port_str == NULL. Exactly
what kind of garbage is undefined... it could be 0 for some
and *real* garbage for others... The check for port!=0 doesn't
suffice to ensure that the value used for port is *valid*.
Note that a garbage value of port that is non-zero would
be used as valid in 2.x right now...
any hints on how to reproduce this problem?

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)

it looks to me that apr_uri_parse() can set port_str to  in some cases where 
there is no explicit port specified and the port integer is set to the default 
port of the scheme:

   uptr-port_str = apr_pstrmemdup(p, s, uri - s);
if (uri != s) {
port = strtol(uptr-port_str, endstr, 10);
uptr-port = port;
if (*endstr == '\0') {
goto deal_with_path;
}
/* Invalid characters after ':' found */
return APR_EGENERAL;
}
uptr-port = apr_uri_port_of_scheme(uptr-scheme);
goto deal_with_path;
in this case, I don't see that checking port_str is going to do the right 
thing...

Maybe I'm barking up the wrong tree, but I get the feeling that maybe the real 
problem is that apr_uri_parse() doesn't return with port and port_str set to 
consistent values, and that this must be fixed anyway, and once it is fixed 
then it doesn't matter whether or not other code checks port or port_str.

Re: the wheel of httpd-dev life is surely slowing down, solutions please


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 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 were happening at
a fast rate. As more and more developers got interested
in getting 2.0 cranked out the (limited) resources all
got eaten up in the 2.0 development cycle and 1.3
development virtually shut down. It was even 'officially'
shut down long before 2.0 was ready ( 1.3 officially went
into maintenance mode only ).

So now you had lots of legacy developers ( albeit... lots
of weekend-warriors, too, but WW's are the heartbeat
of Open Source ) who knew 1.3 very well but were now
totally put out to pasture. Very few of them 'came over'
to the 2.0 development. The majority of the developers
for 2.0 were the 'paid to play' kind that were either being
paid to directly work on Apache ( I'll get to the Covalent
factor in a second ) or,  at least, were being paid to
do something else but no one seemed to mind if they
sat there at their real jobs all day and did Apache
development. They might not admit to being directly
paid to work on Apache but when that's what you are
doing all day and still bringing home a paycheck then
that's exactly what that is.

The 'other' not-so-dedicated-but-certainly-interested 
developers felt 'shut out' of the 2.0 development cycle
because it was obvious a lot of it was taking place
'off line' and nothing was being documented so they
couldn't really get a good handle on what was going
on in order to make a contribution.

So they were mostly 'waiting in the wings' for a lot of
the 2.0 DESIGN level decisions and concepts to 
become clear so they could 'jump in'.

Well... we all know that it was a looong time before
some of the 2.0 design concepts became 'clear' enough
for a not-paid-to-work-on-apache person to 'jump in'.

There were basically only 2 big changes to Apache 2.0
versus 1.x.

1. MPM. Get out of the 'prefork' only 'go fork thyself' design model.

2. ( Came later ) Add some I/O filtering and get rid of BUFF.

Well, these are both fine goals to have but they are not for
the faint-of-heart ( or within the grasp of most weekend-warriors ).

That brings me to The Covalent Factor.

Is anyone going to deny that at a certain point in the 2.0
development cycle the PRIMARY driving force was a 
group of people that ALL worked for one company? ( Covalent ).

That's certainly the way it looked.

...and these guys were crankin'... I mean they were
MOTIVATED, because Covalent's entire corporate
life revolves around Apache and they were actually 
high level deals going on with Compaq ( and other
corporate entities? ) that all revolved around getting
Apache 2.0 out the door.

At one point one of the Covalent guys ( I believe it
was that Randy Bloom fellow? ) was pretty much the
ONLY person who had any idea how the new 'filtering'
was even SUPPOSED to work. It was quite some time
before he even finished thinking it through and it went
through (too?) many re-works to even keep a good
grasp on it.

I remember the feeling for MONTHS was something like...
let's just see what Covalent comes up with and let them
put their stamp of approval on it and then we'll see if
we understand it.

...and that's pretty much how the entire SECOND primary
goal of Apache 2.0 was achieved. Covalent just did it
and expected everyone else to 'go along'... and they did.

The point of all this is not to FLAME anyone or any corporate
entity. No one can deny that Covalent has been crucial to 
the life and times ( and success ) of Apache itself and they
should be proud of the contribution(s) they have made to
OSS. Covalent was started by one of the original Apache guys 
and some of the best developers left around here still work for 
Covalent. I think William Rowe still does, for example, and he's 
still pretty much the only human being who seems to understand 
the Windows version of Apache... but the legacy flood of 'covalent' 
email addresses showing up at httpd-dev has virtually
vanished so it's hard to tell what what with that anymore.

There is nothing in the rules of Open Source that says you
can't crank up a company that makes money off of Open
Source software. Indeed... if you look at almost ALL of the
major Open Source projects you will see the same sort
of 'Covalent' deal going on whereby the people that know
that OSS best have found a way to get paid to work on it.

My only real point here ( and the way all this relates to the
current thread ) is that maybe it's time to acknowledge that
what is happening now is what will always happen to a major
development project if you let too many of your

Re: the wheel of httpd-dev life is surely slowing down, solutions please

2003-11-13 Thread Justin Erenkrantz

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 for awhile.

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 perspective that what
we have in HEAD is roughly what should be in 2.2 modulo testing.)

Ideally, once we start producing 2.2 releases on a regular basis, we
won't be producing 2.0 releases on such a regular basis.  -- justin

Re: the wheel of httpd-dev life is surely slowing down, solutions please

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 perspective that what
 we have in HEAD is roughly what should be in 2.2 modulo testing.)
 

I'm confused then... I had thought that there were API differences
(within httpd and apr) between the 2 trees in able to support
some of the new features.
-- 
===
   Jim Jagielski   [|]   [EMAIL PROTECTED]   [|]   http://www.jaguNET.com/
  A society that will trade a little liberty for a little order
 will lose both and deserve neither - T.Jefferson

Re: should input filter return the exact amount of bytes asked for?

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 readbytes data. */
   AP_MODE_READBYTES,
   ...
Aha! I was looking in the wrong place then. Thanks Justin.

Should we add an explicit explanation to AP_MODE_READBYTES: return at most 
readbytes data. Can't return 0 with APR_BLOCK_READ. Can't return more than 
readbytes data.

Also while we are at it I have a few more questions:

/** The filter should return at most one line of CRLF data.
 *  (If a potential line is too long or no CRLF is found, the
 *   filter may return partial data).
 */
AP_MODE_GETLINE,
does it mean that the filter should ignore the readbytes argument in this mode?

/** The filter should implicitly eat any CRLF pairs that it sees. */
AP_MODE_EATCRLF,
does it mean that it should do the same as AP_MODE_GETLINE but kill CRLF? If 
not how much data is it supposed to read? Or is it a mode that never goes on 
its own and should be OR'ed with some definitive mode, e.g.:
AP_MODE_GETLINE|AP_MODE_EATCRLF and AP_MODE_READBYTES|AP_MODE_EATCRLF?

right? Or how otherwise would you explain the assertion:

   AP_DEBUG_ASSERT(!APR_BRIGADE_EMPTY(bb));


If using APR_BLOCK_READ, it's illegal to return 0 bytes with 
AP_MODE_READBYTES - that is what this assert is checking for in 
maintainer mode (this was a troublesome assert at one point).  It's the 
same expectation as doing a blocking socking read() - blocking reads 
shouldn't return until something is returned.  -- justin
Cool:

/** Determines how a bucket or brigade should be read */
typedef enum {
APR_BLOCK_READ,   /** block until data becomes available */
APR_NONBLOCK_READ /** return immediately if no data is available */
} apr_read_type_e;
Though it'd be nice to add a note re: APR_BLOCK_READ in the AP_MODE_READBYTES 
doc above. Or I guess may be it belongs to some filters tutorial...

__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Re: [PATCH] UseCanonicalName (1.3/2.x)

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
of using a valid 'port' is documented and correctly used in
other locations (such as mod_proxy). The actual URI code works
as advertised; we weren't just *using* it as advertised.

 
 it looks to me that apr_uri_parse() can set port_str to  in some cases where 
 there is no explicit port specified and the port integer is set to the default 
 port of the scheme:
 

Which is fine... If there is no explicit port, then setting port
to the scheme default port is safe (and expected). 

-- 
===
   Jim Jagielski   [|]   [EMAIL PROTECTED]   [|]   http://www.jaguNET.com/
  A society that will trade a little liberty for a little order
 will lose both and deserve neither - T.Jefferson

Re: the wheel of httpd-dev life is surely slowing down, solutionsplease

2003-11-13 Thread Matthieu Estrade

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 
subject and patches.
Finally, i sent an email to concerned people and i get answer it was a 
good job. The patch was not commited.
Then i continued working on it and made it more stable (the more i am 
able...) I posted it few times again on the dev@ and on bugzilla, no 
more answer during one month...
Then, Jeff Trawick get it and it become faster, lots of mail and 
communication, and finally, the patch was commited last week.

I understand core team have a lot of work reviewing, implementing new 
features, patching and fixing bugs... But on the other side (mine), it's 
really discouraging to don't get answer during 3-4 month about work i did.
I needed this patch for my company and it was working here... so finally 
there is no problem it was commited or not...
This slow answer and when there is, is bad for people who submit/write 
patches...
Maybe a new patch management or more people able to commit/review 
experimental/modules only would be good. It could encourage people to 
participate more in apache httpd project.
I can speak with many cool people on IRC and apache channels which is 
why i continue effort, but people not in this case will i think, not try 
a lot to help.

This is not reproach or bad mind about people in apache, but it's just 
a feedback about somebody who try to help and participate.
I hope my english was not too bad and there isn't wrong sense in what i 
said.
People who use to speak with me should understand...

Matthieu

Jeff Trawick wrote:

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 the current order of Committing and Reviewing for the stable 
branch, helping out with reviews would result in fixes being merged 
into the stable branch much faster.

Re: the wheel of httpd-dev life is surely slowing down, solutionsplease