On Sun, 16 Nov 2003, Jeff Trawick wrote:
*** We need to get back many of the disenfranchised Apache 1.3 developers
Who are these people?
/me raises a hand
People have suggested that we have fewer developers today because Apache 2
is too complex. That the crappy economy has reduced the
On Sun, 16 Nov 2003, Jeff Trawick wrote:
Too bad all these supposedly-disenfranchised people aren't around to review 1.3
fixes. 1.3 would be healthier if they were.
And it is the reason for why they are not around that is in question here.
Why wouldn't there be plenty of hackers around for
On Sun, 16 Nov 2003, Graham Leggett wrote:
I think the key thing is bugfixes compared to features and
architecture changes.
I am +1 on seeing bugfixes go into v1.3 - people are using it, and if it
can work better, so be it. But to actively encourage people to add
features or architecture
On Sun, 16 Nov 2003, Jeff Trawick wrote:
The point was not to blame anybody. Instead, I don't believe there are so many
people as you imply. Many of the people who are no longer developing have
moved on to other interests/work/etc. and have dropped out of httpd dev because
of that.
If
On Sun, 16 Nov 2003, Jim Jagielski wrote:
So a useful topic is: What is *missing* in 1.3 that needs to be
addressed.
What are the features/additions that the disenfranchised 1.3 developers
want to add to 1.3...
How about support for chunked compressed responses right in
src/main/buff.c
On Sun, 16 Nov 2003, Marc Slemko wrote:
3. Threading issues. This is a red herring; threading issues can be a
reason why moving to 2.0 wouldn't give someone enough of a reason to make
it worthwhile, but they do not block anyone moving to 2.0. if they
don't want to use threads, they don't
On Mon, 17 Nov 2003, Ian Holsman wrote:
I belive 2.0 beats 1.3 on these metrics, but like everyone here, Ihave
no more energy proving/disproving which is faster.. 2.0 works for me,
and thats all I really care about, not who else is using it.
Do you really believe this to be true for
On Mon, 17 Nov 2003, Bill Stoddard wrote:
Apache 1.4, an APR'ized version of Apache 1.3 (to pick up IPV6 and 64 bit support)
with all the Windows
specific code stripped out and source compatability (to the extent possible) with
Apache 1.3 modules would
probably see rapid uptake. I can't
On Mon, 17 Nov 2003, Jim Jagielski wrote:
Glenn wrote:
On Mon, Nov 17, 2003 at 01:31:55PM -0500, Bill Stoddard wrote:
Apache 1.4, an APR'ized version of Apache 1.3 (to pick up IPV6 and 64 bit
support) with all the Windows specific code stripped out and source
compatability (to
On Mon, 17 Nov 2003, Jim Jagielski wrote:
On Nov 17, 2003, at 2:22 PM, Bill Stoddard wrote:
In this economic environment (and perhaps this will turn out to be
generally true from now on), companies are not making investments in
IT unless they can get a proven and almost immediate return
On Tue, 9 Mar 2004, Jim Jagielski wrote:
There are a few open patches floating about,
but in general I think
we're close to a point where we should seriously consider
patches).
On Jun 8, 2004, at 5:10 PM, Rasmus Lerdorf wrote:
Uh, I never received anything on this. Did you actually send me
something? I'll have a look at addressing this issue. Releasing
1.3.32
without this fix would be a nasty backwards step. The original problem
this fixes
On Wed, 9 Jun 2004, Joe Orton wrote:
On Wed, Jun 09, 2004 at 09:21:07AM -0700, Rasmus Lerdorf wrote:
Don't see that anywhere. Either eaten by spam filters or a gerbil.
Anyway, I don't understand why this would have broken mod_dav. If mod_dav
wants a keepalive connection it should
On Wed, 9 Jun 2004, Joe Orton wrote:
When ap_die() is called, ap_set_keepalive() has not been called, and
r-connection-keepalive is set to 0, as it was initialized so.
The last thing ap_die does is call ap_send_error_response, which calls
ap_send_http_header, which calls ap_set_keepalive,
On Wed, 9 Jun 2004, Jim Jagielski wrote:
On Jun 9, 2004, at 3:24 PM, Rasmus Lerdorf wrote:
I guess what we are agreeing on here is that the logic that sets
keepalive
to 0 is faulty and that is probably where the real fix lies.
yeah... it's pretty inconsistent. Looking at ap_set_keepalive
We still have that outstanding issue of conn-keepalive being bogus in
ap_die() because it hasn't been set yet and thus we can't discard the
request body in situations where we really need to. See my previous long
explanation of that problem.
-Rasmus
On Sat, 3 Jul 2004, Jim Jagielski wrote:
wrote:
Yes, we do, and we're still waiting for a patch. However,
I can't see us delaying 1.3.32 for an unreasonable
amount of time.
On Jul 5, 2004, at 10:54 AM, Rasmus Lerdorf wrote:
We still have that outstanding issue of conn-keepalive being bogus in
ap_die() because it hasn't been set
Yeah, I am not keen on the notes table approach either. My original patch
to fix this didn't do that. Not that my patch was great either.
The problem with calling ap_set_keepalive() multiple times is that the
function doesn't just set the keepalive flag, it also increments the
connection's
On Fri, 27 Aug 2004 [EMAIL PROTECTED] wrote:
/*
+ * We need to ensure that r-connection-keepalive is valid in
+ * order to determine if we can discard the request body below.
+ */
+ap_set_keepalive(r);
I realize you probably just took my wording there, but it
I had used the same approach but just had it external. Putting it inside
is a better idea. I still think it is dumb that this isn't called at a
much earlier stage, but changing that is more likely to break stuff than
this approach.
-Rasmus
On Sat, 28 Aug 2004, Jim Jagielski wrote:
Here is, I
On Tue, 7 Sep 2004, Geoffrey Young wrote:
the attached patch is a direct port of the logic from 2.0 to 1.3. thoughts
or insights on why this wouldn't be a good idea for 1.3 or other feedback
appreciated.
Seems like a good idea to me.
-Rasmus
On Tue, 7 Sep 2004, [ISO-8859-15] André Malo wrote:
* Jim Jagielski [EMAIL PROTECTED] wrote:
I'd like to propose a 1.3.32 release with a TR either late this
week or early next.
Sounds good.
Though I'd like to point to the 2.0 status file, where a bugfix (to 2.0
and 1.3) is waiting for
On Wed, 8 Sep 2004, [ISO-8859-15] André Malo wrote:
* Jim Jagielski [EMAIL PROTECTED] wrote:
In general, people don't look for 1.3 patches in the 2.0 STATUS file
and vice-versa :)
As far as I can see, the current way to make changes is 2.1 - 2.0 - 1.3.
So it makes sense for me to look
On Wed, 8 Sep 2004, [ISO-8859-15] André Malo wrote:
Actually I'm talking about the two proposals on the top. If you are
interested in backport voting, you need to touch the STATUS file anyway and
should follow the commits there.
I'd still suggest posting them here. Until the lawyers here
William A. Rowe, Jr. wrote:
Joseph Dane wrote:
Joshua Slive [EMAIL PROTECTED] writes:
In very early versions of the Apache HTTP Server, the
directiveAddType/directive directive was also used to activate
special server-side processing (such as modulemod_include/module
or PHP) by assigning
Jim Jagielski wrote:
Please test and vote on releasing Apache httpd 1.3.36
Download from:
http://httpd.apache.org/dev/dist/
Changes:
http://httpd.apache.org/dev/dist/CHANGES_1.3
Works ok on Debian-unstable with the standard set of Debian patches
applied. It might be time to roll in
Sebastian Nohn wrote:
I fear that many users of Apache would actually turn off the
Server header for no or for the wrong reasons (which may harm our
market share), and therefore I'm -1 on including this patch.
It would not change apaches market share. If you are talking about
netcraft (and
On Thu, 30 Dec 2004, Paul Querna wrote:
It is impossible with the current way virtual hosts and document roots
are handled.
I guess doing it per-conf Apache1-style, as in:
conf = ap_get_module_config()
conf-ap_document_root = ...;
Just sets the root server's docroot then now. Not being
On Fri, 31 Dec 2004, Nick Kew wrote:
On Thu, 30 Dec 2004, Paul Querna wrote:
Just sets the root server's docroot then now. Not being able able to
manipulate the document_root is a rather severe limitation as far as I am
concerned.
I agree. But to fix it properly, we need a
On Fri, 31 Dec 2004, Nick Kew wrote:
On Thu, 30 Dec 2004, Rasmus Lerdorf wrote:
Nobody is saying anything about doing it anywhere within a request.
Huh? What are you smoking?
obviously you can't change the doc_root after the fact, but I see no
reason to not be able to do it prior
On Thu, 30 Dec 2004, Paul Querna wrote:
Rasmus Lerdorf wrote:
[snip]
Hint: document root is a configuration value used *by default* in
filename translation. Any module can implement its own translation
hook, but trying to change a core configuration value is not only
utterly pointless (your
Why is it hardcoded to be 8000? It would seem like you could easily be
unlucky and just miss the cutoff and end up with a 6000 byte heap bucket
followed by a 3000 byte transient bucket, for example, as a result of 3
3000 byte ap_rwrites. For that particular case it might be quite
beneficial
Cliff Woolley wrote:
On Fri, 7 Jan 2005, Rasmus Lerdorf wrote:
Why is it hardcoded to be 8000? It would seem like you could easily be
unlucky and just miss the cutoff and end up with a 6000 byte heap bucket
followed by a 3000 byte transient bucket, for example, as a result of 3
3000 byte
Cliff Woolley wrote:
It might be. We've considered having it be configurable before. There
are just a lot of implications in changing the value; for example, it
affects the memory footprint of the server, it affects how much data gets
read in to memory per read() call on a file bucket (which
On Wed, 12 Jan 2005, Paul Querna wrote:
- The entire AcceptFilter/TCP_DEFER_ACCEPT code needs to be refactored
to properly work with different protocols.
Has anybody here had a look at implementing httpready for Linux or is the
'just use Tux' camp still winning this one? I had a quick look,
Paul A. Houle wrote:
On Linux I've done some benchmarking and found that worker isn't
any faster than prefork at serving static pages. (Is it any different
on other platforms, such as Solaris?) In principle you might save RAM
by running prefork, but in this day and age you can fit 16
William A. Rowe, Jr. wrote:
For anyone who wants to argue that this is a PHP-caused anomaly, note also
http://www.securityspace.com/s_survey/data/man.200501/apachemods.html
-10% followed by +11% the following month:
http://www.securityspace.com/s_survey/data/man.200502/apachemods.html
Big swings
Turn on accept filtering and this problem goes away. Or at least it
moves to be a kernel-level issue instead of an Apache one.
-Rasmus
Ivan Barrera A. wrote:
Hi...
I'm still fighting (probably for a lost cause.. but my boss ask me to
do this).
In the socket activity there are some troubles
Ivan Barrera A. wrote:
It doesn't.
How so? With accept filtering, simply opening up the socket doesn't
trigger Apache in any way, so how is Apache DoS'ed in that case? And
under FreeBSD with the httpready filter you can trickle really slow
requests over the socket and Apache still won't see
Ivan Barrera A. wrote:
How about linux ? how about Windows ? how about (put your favorite OS
here) ?
Linux has SO_ACCEPTFILTER which doesn't trigger the accept until there
is data, so accept filtering works on Linux too. Windows? No idea.
But I bet an Apache DoS would be the least of your
Nick Kew wrote:
Turn on accept filtering and this problem goes away. Or at least it
moves to be a kernel-level issue instead of an Apache one.
How does that work with large requests? Doesn't the whole principle
leave you the choice of just moving the DOS attack or breaking
pipelining?
You mean
Ivan Barrera A. wrote:
I haven't been able to enable acceptfilters on linux. Where can i get a
howto or some info ?
Sorry, I led you slightly astray. SO_ACCEPTFILTER is for FreeBSD. In
Linux the option is referred to as TCP_DEFER_ACCEPT and I don't actually
think this is implemented in the
Nick Kew wrote:
I have some recollection of that problem, but not the solution. It's
actually somewhat topical for my client right now. You and Paul have
told us about FreeBSD and Linux; is there also a Solaris equivalent?
(probably not required as they're gradually upgrading it to Linux,
but
Paul Querna wrote:
Rasmus Lerdorf wrote:
Ivan Barrera A. wrote:
I haven't been able to enable acceptfilters on linux. Where can i get a
howto or some info ?
Sorry, I led you slightly astray. SO_ACCEPTFILTER is for FreeBSD. In
Linux the option is referred to as TCP_DEFER_ACCEPT and I don't
Paul Querna wrote:
In real life, I don't believe this is detrimental, since if the
accf_http filter sees data it doesn't understand, it acts just like
accf_data -- and mod_ssl reads the data just like normal.
Hrm.. I am not sure I am convinced of that based on what I have seen on
some
Paul Querna wrote:
The Problem:
We do not know what protocol will be used to handle a connection until
runtime. We currently cannot determine this at startup.
This results in:
Primary: Accept Filters and TCP_DEFFER_ACCEPT are currently not used
correctly. The 'httpready' accept
Paul Querna wrote:
So, here is my short-list-made-up-this-afternoon of things I would like
to look at doing after 2.2 is branched/released as GA. I welcome
additions too.
1) Eliminate the HTTP in HTTPD. I would like to be able to compile
httpd with --disable-http. Currently the 'http
Enrico Weigelt wrote:
Hi folks,
I'd like to stop httpd from detaching itself, so I can start
it from init.
How can this be done ?
httpd -X if you want a single non-forking non-detached process
httpd -F if you just want the main process to be non-detached and still
have it
You mean when you send a request header that looks something like this?
~ telnet localhost 80
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET / HTTP/1.1
Host: localhost
Connection: foo
HTTP/1.1 200 OK
Date: Wed, 20 Nov 2002 22:52:24 GMT
Server: Apache/1.3.28-dev (Unix)
+1 on committing this. I finally got around to testing it.
-Rasmus
On Thu, 7 Nov 2002, Andrei Zmievski wrote:
Hello,
I am submitting a patch to mod_usertrack for your consideration.
This patch was developed here at Fast Search Transfer for
alltheweb.com and provides the following
In cvs? But no, it has not. Everyone seems to be ignoring 1.3 these
days.
-Rasmus
On Wed, 27 Nov 2002, Andrei Zmievski wrote:
Where can I check if it's been committed or not?
On Fri, 22 Nov 2002, Rasmus Lerdorf wrote:
+1 on committing this. I finally got around to testing
You can also see text in our bug database from a prominent PHP developer
saying that the filter API needs to be redone from scratch (my
paraphrase). For the enthusiastic PHP users, such comments carry a lot
of weight and imply that PHP isn't production ready with 2.0 not because
nobody
What I think is useful information to people who want PHP+Apache-2.0 is:
a) is PHP not production ready with Apache 2.0 because it was not high
enough priority for PHP to be tested?
That is a big part of it. The fact that the thread-safety of many
third-party libraries that can be linked
On Wed, 5 Feb 2003, Joshua Slive wrote:
On Wed, 5 Feb 2003, Sascha Schumann wrote:
Now, we could solve both problems by using a handler and
the prefork MPM. But then, Apache 2.0+PHP is basically
Apache 1.3+PHP with a few extra modules thrown in. That's
how it appears to
Is it really #1 module?? *sigh*
Yup, by far.
From my experience and that of some of programmers I know, PHP people are
very reluctant to admit that they have bugs or fix their bugs. Usually
they find it better to argue that you're the idiot and their code works
(even when it does not).
Perhaps it's best for someone to simply port php4apache to 2.0 and start
moving a little momentum. The thread-safety arguement is a little bogus,
until folks have something to start finding thread-safety bugs. How long
have Win32 users been doing PHP within threaded servers?
We have gotten
Do you really think we don't know this?
The point is that at this point we would basically have to mutex every
call to every 3rd-party library function since we simply don't know which
ones are threadsafe and which ones aren't. And if we lock everything,
isn't it simpler to just go prefork
On to a). The PHP developers have screamed quite loudly about the
failings of Apache2, when, in fact, the largest reason why mod_php will
not work with Apache2 is because it is not a priority for PHP developers.
Nobody is screaming.
Personally, my servers run PHP as CGI. Works well. Thank
In doing a bit of performance tweaking on 1.3, I noticed that
ap_send_header_field() does an ap_rvputs() with each little piece of a
header which results in separate ap_bwrite() calls for Primitive, :,
Value, crlf for each header line sent. Rather than having these 1 and
2 character ap_bwrite()
Are per-dir configs available before the uri-filename translation handler
in 1.3.x, or do they apply to the translated filenames and thus any config
directives accessed by the filename translation hook can only be
server-wide?
And is this the same in 2.0.x?
It would make sense to me for this to
Multiple filters in the chain for each classification can exist
(ordering between classifications shouldn't matter...) This
way you can have a URL handled by mod_include and mod_php (but
the mod_include portion can't create PHP tags and vice versa
since you can't guarantee when it will run
It shouldn't. You potentially need to protect yourself from NULL r-filename
(we haven't decided what to do yet with *this*is*not*a*file* requests.) Since
PHP generally serves -files-, this won't be a huge change for you. For serving
from an SQL database, or proxied requests, or internal
Whoa, deja vu... I could have sworn I fixed something very similar to
this more than 5 years ago now. In fact, here is the patch for Apache
1.2.x:
Fri Mar 1 03:01:06 1996 UTC (66 months, 1 week ago)
http://cvs.apache.org/viewcvs.cgi/apache-1.2/src/http_request.c.diff?r1=1.2r2=1.3
Not exactly
I am getting rather tired of answering questions on this one. Could we
please drop this crap about htpasswd using md5. A modified md5 is no
longer md5, so let's not call it md5 at all. Over and over again people
ask me why md5($string) doesn't match what is in htpasswd-generated
password
there will be at
least one more implementation of md5 to cope with.
Thanks for listening,
David
Rasmus Lerdorf wrote:
I am getting rather tired of answering questions on this one. Could we
please drop this crap about htpasswd using md5. A modified md5 is no
longer md5, so let's not call
There is no static library support for PHP with Apache 2 at this point.
ie. you can only build using --with-apxs2 (if you are lucky)
Sometime down the road we will probably add this, but it definitely will
not be in 4.2. Perhaps 4.3.
-Rasmus
On 9 Apr 2002, Austin Gonyou wrote:
so for say
, Cliff Woolley wrote:
On Fri, 3 May 2002, Rasmus Lerdorf wrote:
Ok, but where should this information go then? Apache has definitely
benefitted by having this information available. Some sort of
X-SERVER-INFO: header then?
What I meant was I don't think the MPM should be announced
My own opinion is that we leave things exactly as they are today. If
you are running the binary by hand, you are taking some responsibility
for knowing what you are doing. That means having the environment
variables setup correctly before you start.
If you don't want that
Right now PATH_INFO is not automatically passed to PHP scripts in the
Apache 2.0 module for PHP. I have a patch on my plate that enables it
by default, but for now you can add AcceptPathInfo On to the directory
or location sections where you want it to work.
That should go in. Why would you
mod_info will tell you some of this. ie. Look for ScriptAlias lines under
mod_alias.c and AddHandler cgi-script lines under mod_mime.c.
But you are fighting a bit of a lost cause here. If you allow users to
upload arbitrary cgi scripts there really isn't much you can do at the
Apache level.
Could someone karma me for apache-2.0 please?
-Rasmus
Someone asked me for numbers when I mentioned the other day that Apache
2-prefork was really not a viable drop-in replacement for Apache 1.3 when
it comes to running a PHP-enabled server.
Apache 1.3 is still significantly faster than Apache2-prefork for both
static and dynamic content. Now,
It would be nice
if there was an apxs flag that would return the MPM type.
+1
There is. -q will query for any value in config_vars.mk, and MPM_NAME
is in that file. So `apxs -q MPM_NAME` will return the configured MPM
type.
Ah right. Is there a way to check at runtime as well?
Runtime is harder, but you can just use ap_mpm_query to get the MPMs
characteristics. This won't give you the MPM name, but it will let you
know if the MPM is threaded or not.
What is the correct way to fail in a filter post_config? Do I return -1
from it if my filter finds a fatal error?
What is the correct way to fail in a filter post_config? Do I return
-1
from it if my filter finds a fatal error? I can't use ap_log_rerror()
at
this point, right? How would I log the reason for the failure?
I'm confused by the question, but I'll try to answer. If you mean the
On Mon, 24 Jun 2002, Rasmus Lerdorf wrote:
What is the correct way to fail in a filter post_config? Do I return
-1
from it if my filter finds a fatal error? I can't use ap_log_rerror()
at
this point, right? How would I log the reason for the failure?
I'm confused
On Mon, 24 Jun 2002, Cliff Woolley wrote:
On Mon, 24 Jun 2002, Rasmus Lerdorf wrote:
Hrm.. Nope. doing 'return DECLINED' from the post_config phase does not
stop the server from starting. I have this:
I thought you were supposed to return HTTP_INTERNAL_SERVER_ERROR.
In include
As it happens, DONE is defined to be -2. :-)
Ok, I will use that, but 'DONE' doesn't really give the impression of
being a fatal error return value.
-Rasmus
* Saying turn on buffering is, IMHO, a reasonable solution if you
can make buffering the default in PHP under httpd-2.0. Otherwise,
you'll surprise a lot of users who have been running with the default
non-buffered output using 1.3 and find that all their applications
are far slower
With Apache 1.3 all you had to do to get a keep-alive was set your
content-length correctly:
HTTP/1.1 200 OK
Date: Mon, 24 Jun 2002 17:05:04 GMT
Server: Apache/1.3.22 (Unix) PHP/4.3.0-dev
X-Powered-By: PHP/4.3.0-dev
Content-length: 1024
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
http://www.apache.org/dist/httpd/patches/ has patches for every released
version of Apache 1.2.x and 1.3.x
On Wed, 3 Jul 2002, Andrew Ho wrote:
Hello,
Is there a patch for earlier versions of Apache that fix the chunked
Transfer-Encoding security hole, but nothing else? I know OpenBSD, for
With this config:
LoadModule php4_modulemodules/libphp4.so
AddType application/x-httpd-php .php
http://localhost/index.php
works fine and parser PHP pages without problems. (using prefork - but it
shouldn't matter)
However: http://localhost/index.php/foo
Gives a 404 and says:
The
On Sat, 6 Jul 2002, Dale Ghent wrote:
On Sat, 6 Jul 2002, Rasmus Lerdorf wrote:
| 2.0.40-dev built on June 23rd
Make sure you have AcceptPathInfo On
Argh! Why the heck is that off by default?
-Rasmus
Make sure you have AcceptPathInfo On
Argh! Why the heck is that off by default?
It's on by default for dynamic pages, but there is no way that Apache
can tell that a page is going to be served by PHP, so it is off for what
Apache thinks are static pages.
What is a dynamic page if not
What is a dynamic page if not a PHP page?
Like I said, Apache doesn't know if a file on disk is meant for PHP or
not. The best way to fix this would be for mod_php to set the value if
the filter is added for the request.
I agree, it would be cool if Apache could set this correctly based
On Sat, Jul 06, 2002 at 03:11:20PM -0400, [EMAIL PROTECTED] wrote:
We just added a new function for all input filters to allow this to be
done (Justin referenced it in his reply). However, that function doesn't
solve the problem, because there should be an ap_filter_is_dynamic(r) that
Hello,
I've more or less accepted that perchild on FreeBSD 4.X isn't going to
happen (as sad as it is, I always considered it to be THE feature [1] in
2.0 that would warrant an upgrade for us) but what I'd like to know is
if there is any chance to see perchild on FreeBSD 5 which gets wholly
I agree with Pier, the threaded MPM has been a real lifesaver. Supporting
10,000+ concurrent clients with Apache 1.3 (including some complex modules)
on AIX and Solaris is practically impossible. Quite doable with Apache 2.0
and the worker MPM.
I am sure it does, but you also need to
I am sure it does, but you also need to recognize that around 40% of all
Apache installations have PHP on them. And 30% or so have mod_perl. Many
actually have both, so there is some overlap, but I would say that over
half of all Apache installs have one or both of PHP or mod_perl.
On Thu, 15 Aug 2002, Justin Erenkrantz wrote:
[ Moving to dev@httpd where this belongs ]
On Thu, Aug 15, 2002 at 07:10:02AM -0700, Rasmus Lerdorf wrote:
Correct. From the feedback I am getting, users do not adequately
understand the implications of choosing a threaded MPM. We need to do
modules' vendors for
more information on their thread-safety.
-g
On Thu, Aug 15, 2002 at 10:09:27AM -0700, Justin Erenkrantz wrote:
On Thu, Aug 15, 2002 at 09:40:06AM -0700, Rasmus Lerdorf wrote:
thttpd/Zeus/boa/Tux/khttpd for that. All I am after is a simple very
visible addition
FWIW, I'm +1 on what Rasmus says - at least for widely used libraries.
Obviously anything internal to PHP is PHP's problem. But anything
everyone uses is our problem.
However, I would advocate fixing the libraries rather than wrapping them
where possible.
Yup, definitely. They aren't
I see them
On Tue, 27 Aug 2002 [EMAIL PROTECTED] wrote:
I realized earlier today that I haven't been seeing commit messages.
Is anybody getting these messages?
Ryan
--
___
Ryan Bloom
On Tue, 3 Sep 2002, Chris Taylor wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[ ] Check in aaa rewrite to 2.0.
[X] Check in aaa rewrite to 2.1.
My view is that it's important to keep 2.0 stable to attract new
users, and breaking things all the time won't help :)
Can
On Tue, 3 Sep 2002, Rasmus Lerdorf wrote:
On Tue, 3 Sep 2002, Chris Taylor wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[ ] Check in aaa rewrite to 2.0.
[X] Check in aaa rewrite to 2.1.
My view is that it's important to keep 2.0 stable to attract new
The ASF is apparently not about working together, since I (and
everyone else who is not on the PMC list) have been entirely left
out of all this conversation which is going on behind closed doors.
Which closed doors are those? There has been discussion on the dev list
and on the board list.
Which closed doors are those? There has been discussion on the dev list
and on the board list. Both of which are public lists that you can
subscribe to.
All I know of is the PMC list (which is private), but discussion on
board (which is also private) is news to me.
Well, I had assumed
Contributions are more than welcome.
On Tue, 10 Sep 2002, Cyrille Artho wrote:
Hi,
as someone who works on multi-threaded problems, but not Apache, I ran
into your page at
http://httpd.apache.org/docs-2.0/developer/thread_safety.html
I strongly suggest to revise it, because it lacks
While we believe that the El-Kabong codebase is a valuable contribution
that we would like to pick up, we also recognize the possibility that
you may have a decreased incentive to work on it further if you are
initially denied commit access to the repository when it moves to the
ASF.
See his domain name. Novell.com
On Sat, 28 Sep 2002, Jim Jagielski wrote:
Ramesh Shankar wrote:
Threads? Is this under Win32?
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
1 - 100 of 101 matches
Mail list logo
