Hi Ian,
Thanks for x-posting it to the apr mailing list.
As regards the shmem_t, you're right.. I'm working on having it as a part of
the shared memory itself - but I'm not sure if such a thing is acceptable..
I was thinking of the following 2 alternatives (1) store the shmem_t
structure in
* On 2001-09-08 at 08:34,
William A. Rowe, Jr. [EMAIL PROTECTED] excited the electrons to say:
I've seen similar requests for require group. While you are cautiously
modifing the 1.3 code base, would you please consider both?
As I said in the preface, the actual patch does both 'require
* On 2001-09-08 at 08:33,
Stas Bekman [EMAIL PROTECTED] excited the electrons to say:
the only thing apxs does on -q KEY is parsing build/config_vars.mk and
giving you the value of the requested key.
Um, that is on 2.0. We are talking about 1.3..
--
#kenP-)}
Ken Coar,
Greg Stein wrote:
There shouldn't be any emotions at this point. There is no contention
between two modules. We are only talking about mod_gz, which Ian posted a
while back.
If that's the the case, then cool. But I feel that mod_gz would not
have the support (or be this far along in the
On Friday 07 September 2001 21:50, Stas Bekman wrote:
On Fri, 7 Sep 2001, Pier Fumagalli wrote:
Bill Stoddard [EMAIL PROTECTED] wrote:
I'd like to tag and roll Apache 1.3.21. Anyone have anything they
would like to get in first? I believe there are some proxy patches and
some misc
On Saturday 08 September 2001 01:33, Justin Erenkrantz wrote:
On Fri, Sep 07, 2001 at 09:08:20PM -0700, Ryan Bloom wrote:
I also do not believe that we should be making this decision right now.
I am 100% in agreement with Jim about this. We should table this whole
discussion until
The absolute best way to stay on top of API changes is to make your
code available to the people making those changes.
Rasmus... We don't want any distractions to the core code until it's
stable. It took 5-6 months to get mod_gzip stable for 1.3.x. I doubt it
will take that long in Apache 2.x
On Friday 07 September 2001 14:23, Brian Pane wrote:
The attached patches change the apr_table_t implementation from
a linear list to a hash table (not an apr_hash_t, though!). With
this change, I'm seeing a ~3% improvement in throughput when
delivering a 0-byte file over the loopback on
hi,
- someone asked me for mod_vhost_alias on Win32, so I compiled it
and it loads into Server, but didnt test more with it; can we add
this to the 1.3 Win32 project or does someone think it will not run
for some reason? (I didnt look at the code because it compiled
without problems).
I do not believe that adding new functionality to the server is the
way to get a release out the door.
Ryan, I agree with you on this point. Apache has to get to solid beta
before ANY new functionality is included. I believe I have backed you on
this subject before. It is simply too much to
On Fri, 7 Sep 2001, Bill Stoddard wrote:
I'd like to tag and roll Apache 1.3.21. Anyone have anything they would
like to get in first?
Is there any chance of merging the mod_env bugfix patch from PR#8254?
Gary
[ Gary Benson, Red Hat Europe ][ [EMAIL PROTECTED] ][ GnuPG 60E8793A ]
on 9/7/01 12:33 PM, Sunitha Kumar at [EMAIL PROTECTED] wrote:
-solaris 2.8, on Forte 6.0
Yes, with a try'n buy of 6.1. Compiling went OK once I made it fully
impossilbe for the configure script to find gcc, but when I tried to
introduce optimization (OPTIM=...), the -O... also got passed to
In a message dated 01-09-08 14:34:49 EDT, Justin wrote...
As most of you know (like I haven't said it enough), I'm going to be
out of regular email contact for a few weeks. But, I hope this
enlightens you on my perspective on what should happen before a
GA is released. I look
On Saturday 08 September 2001 11:29, Brian Pane wrote:
Ryan Bloom wrote:
On Friday 07 September 2001 14:23, Brian Pane wrote:
The attached patches change the apr_table_t implementation from
a linear list to a hash table (not an apr_hash_t, though!). With
this change, I'm seeing a ~3%
The latter. Having two API's to the same functions should only be done
as a stop-gap.
I disagree. It's inevitable to have two APIs, as long as we have two
'table' types with very different semantics.
apr_table_t is statically typed (uses char*), and apr_hash_t isn't (uses
void*).
If
In a message dated 01-09-08 17:43:15 EDT, Ryan wrote...
I know that there aren't many modules for 2.0 today, but at some
point, everybody who has a module for 1.3 will want to port it to 2.0. I
can currently do that in under one hour for even complex modules.
Changing API's like this
Ryan Bloom wrote:
The latter. Having two API's to the same functions should only be done
as a stop-gap.
I disagree. It's inevitable to have two APIs, as long as we have two
'table' types with very different semantics.
apr_table_t is statically typed (uses char*), and apr_hash_t isn't (uses
[EMAIL PROTECTED] wrote:
In a message dated 01-09-08 17:43:15 EDT, Ryan wrote...
I know that there aren't many modules for 2.0 today, but at some
point, everybody who has a module for 1.3 will want to port it to 2.0. I
can currently do that in under one hour for even complex modules.
William A. Rowe, Jr. wrote:
From: Brian Pane [EMAIL PROTECTED]
Sent: Friday, September 07, 2001 2:23 PM
The attached patches change the apr_table_t implementation from
a linear list to a hash table (not an apr_hash_t, though!). With
this change, I'm seeing a ~3% improvement in
On Saturday 08 September 2001 16:42, Ian Holsman wrote:
William A. Rowe, Jr. wrote:
From: Brian Pane [EMAIL PROTECTED]
Sent: Friday, September 07, 2001 2:23 PM
The attached patches change the apr_table_t implementation from
a linear list to a hash table (not an apr_hash_t, though!).
On Saturday 08 September 2001 15:25, Brian Pane wrote:
Ryan Bloom wrote:
The latter. Having two API's to the same functions should only be done
as a stop-gap.
I disagree. It's inevitable to have two APIs, as long as we have two
'table' types with very different semantics.
apr_table_t
Ryan Bloom wrote:
On Saturday 08 September 2001 15:25, Brian Pane wrote:
Ryan Bloom wrote:
The latter. Having two API's to the same functions should only be done
as a stop-gap.
I disagree. It's inevitable to have two APIs, as long as we have two
'table' types with very different semantics.
From: Rodent of Unusual Size [EMAIL PROTECTED]
Sent: Saturday, September 08, 2001 5:49 AM
* On 2001-09-08 at 08:34,
William A. Rowe, Jr. [EMAIL PROTECTED] excited the electrons to say:
I've seen similar requests for require group. While you are cautiously
modifing the 1.3 code base,
From: Günter Knauf [EMAIL PROTECTED]
Sent: Saturday, September 08, 2001 9:03 AM
- I've used a patch against mod_autoindex which enables setting of colors
with server generated indexes and it works fine; no I wanted to build
mod_autoindex as separate module, but when I do so mod_autoindex runs
Hello all...
Kevin Kiley here..
I spent the day talking to Dr. Mark Adler ( co-author of ZLIB )
with the specific focus being certain issues that are on the
table here at the Apache forum.
As Peter (Cranstone) and I mentioned in the exchange last week
( but things got lost in the noise )
wrowe 01/09/08 23:03:05
Modified:.CHANGES
file_io/netware filesys.c
file_io/os2 filesys.c
file_io/unix filepath.c
file_io/win32 filepath.c filesys.c
include apr_file_info.h apr_thread_proc.h
26 matches
Mail list logo
