On Mon, Nov 12, 2018 at 1:26 AM Ruediger Pluem wrote:
>...
> The discussion died a little bit, because of the other issue (frequent
> writeev calls).
> I know that the liveprops issue is not fixed yet, but I guess it makes
> sense
> if you commit the patch you posted here already.
>
My time has
On Fri, Jan 25, 2019 at 2:47 PM Chris Punches
wrote:
> Someone may want to add some text along the lines of when to use u/WSGI
> instead of mod_lua as that's going to be a thing if this goes stable. If
> the what/when isn't in there clearly we could run into really bad
> situations like ASF usin
On Sun, Oct 6, 2019, 11:52 Roy T. Fielding wrote:
> > On Oct 5, 2019, at 1:09 PM, Jim Jagielski wrote:
> >
> > Various PMCs have made their default/de-facto SCM git and have seen an
> increase in contributions and contributors...
>
Not because of git, but due to GitHub. Git is "meh", but GitHub
On Tue, Oct 8, 2019 at 3:13 AM Joe Orton wrote:
> On Sat, Oct 05, 2019 at 04:09:34PM -0400, Jim Jagielski wrote:
> > Various PMCs have made their default/de-facto SCM git and have seen an
> > increase in contributions and contributors...
> >
> > Is this something the httpd project should consider
On Tue, Oct 8, 2019 at 4:45 AM Nick Kew wrote:
>...
> OK, that's not quite fair. But isn't that what the github mirror is for?
>
Not even close to fair, stop that.
The github mirror is readonly. As noted upthread, that means merging PRs
and other activities are limited. It cannot act as a road
On Wed, Oct 9, 2019 at 7:59 AM Michal Karm wrote:
> On 10/08/2019 10:44 AM, Greg Stein wrote:
> > On Tue, Oct 8, 2019 at 3:13 AM Joe Orton > <mailto:jor...@redhat.com>> wrote:
> >
> > On Sat, Oct 05, 2019 at 04:09:34PM -0400, Jim Jagielski wrote:
>
On Tue, Oct 15, 2019 at 1:42 AM Ruediger Pluem wrote:
>...
> Would we lose this possibility [of editing log messages] with git?
>
Yes.
The log message is part of the commit hash. You can effectively delete the
"tip" commit of a line-of-development, and replace it with a new commit
(ie. same cod
$ svn info --show-item last-changed-revision $whatever
I think that's what you're looking for, in a simple command.
On Sat, Jan 18, 2020 at 9:00 AM wrote:
> Author: druggeri
> Date: Sat Jan 18 15:00:05 2020
> New Revision: 1872960
>
> URL: http://svn.apache.org/viewvc?rev=1872960&view=rev
> Log
On Wed, Apr 29, 2020 at 8:19 AM Joe Orton wrote:
> On Tue, Apr 28, 2020 at 05:19:09PM +0200, Ruediger Pluem wrote:
> > +1 g...@httpd.apache.org (I declare the naming discussion for the list
> name opened :-)).
> > This offers an easy opt-in for those who are interested in these updates.
>
> +1 fr
Hey Graham ... what's the goal with exposing these things? (this rev, and
prior) ... I don't see any emails describing "why". Generally, it would be
"shrug" ... but you're changing the MMN, and I don't see any discussion on
why/goal.
Thanks,
-g
On Sun, Jun 28, 2020 at 8:17 AM wrote:
> Author:
Seems these helper functions would be a better fit within apr_xml, rather
than httpd.
On Wed, Jul 15, 2020 at 8:16 AM wrote:
> Author: minfrin
> Date: Wed Jul 15 13:16:19 2020
> New Revision: 1879888
>
> URL: http://svn.apache.org/viewvc?rev=1879888&view=rev
> Log:
> mod_dav: Add utility functi
You're already changing the API ... why not simply introduce
insert_prop_v2() with the appropriate parameters? This concept of "pass
parameters via the pool" is very disturbing.
Cheers,
-g
On Wed, Jul 15, 2020 at 8:56 AM wrote:
> Author: minfrin
> Date: Wed Jul 15 13:56:55 2020
> New Revision:
On Wed, Oct 26, 2022 at 1:59 PM Emmanuel Dreyfus wrote:
> On Tue, Oct 18, 2022 at 05:03:48PM +, Emmanuel Dreyfus wrote:
> > dbm is fast once you have it open. mod_dav_fs opens DAVLockDB on each
> > HTTP request, then it acquire a filesystem level lock on it. This is
> > where contenton occurs
On Thu, Oct 27, 2022 at 8:22 AM Emmanuel Dreyfus wrote:
> On Thu, Oct 27, 2022 at 01:58:58AM -0500, Greg Stein wrote:
> > With that said, I'm not a fan of [DAV or svn] locks. Anything that can be
> > done to avoid a workflow that encompasses locks would be ideal.
>
&
F/OSS is not about telling others how to write their code, Joe. You know
this. And it *definitely* is not about demanding they spend *their* time to
fix your pet issues.
If you have a problem with the code, then supply a fix. Your dozen emails
are not fixing anything, and are certainly not endeari
On Tue, Apr 25, 2023 at 1:45 AM Ruediger Pluem wrote:
>...
> 2. Switching from Subversion to Git is mostly an emotional problem for me.
> We have some closer ties to Subversion by some
>overlaps in the community and via mod_dav_svn we kind of partially eat
> our very own dogfood here by using
+1 for switching to GitHub (which implies a switch to git). So:
[X]: Move the read/write repository from Subversion to Git and leverage the
features of Github (for now Actions and PR).
On Thu, May 4, 2023 at 3:34 AM Ruediger Pluem wrote:
> This is a formal vote on whether we should move our re
On Fri, May 5, 2023 at 2:12 AM Dennis Clarke wrote:
>...
> Why the assumption of Microsoft github? There is no reason to
> migrate to a git service such as Microsoft github when sourcehut works
> just fine as does a private git repo provided by Apache FSF itself.
>
Because the Apache Instr
On Fri, May 5, 2023 at 3:19 AM Dennis Clarke wrote:
>
> > Everybody says git is decentralized, so why are you even asking this
> > question? Can't you just use any git repository, anywhere? ;-)
>
> Github is microsoft and you can bet they will break things. It is only a
> matter of time with them
I might suggest another day or two because of the weekend and because it is
so high-impact. Maybe an extra post to private@ in case some PMC members
aren't tracking dev@ very closely.
On Mon, May 8, 2023 at 1:42 AM Ruediger Pluem wrote:
>
>
> On 5/4/23 10:34 AM, Ruediger Pluem wrote:
> > This i
On Mon, May 8, 2023 at 4:29 AM Graham Leggett via dev
wrote:
> On 04 May 2023, at 09:34, Ruediger Pluem wrote:
>
>...
> > [X]: Leave everything as is.
>
> I would rather see proper SVN integration with Github. This is a vote of
> no confidence in our own projects.
>
What do you mean by "integr
On Mon, May 8, 2023 at 9:08 AM Stefan Sperling wrote:
>...
> If the ASF at large was confident in SVN as a technology then our current
> reality would look quite different. The Subversion project never managed
> to grow its developer base by becoming part of the ASF. We've mostly seen
>
That is
On Wed, May 10, 2023 at 5:18 AM Stefan Sperling wrote:
>...
> I did have some hope that we would see individual self-motivated
> contributors
> arriving via various ASF projects because they are all using SVN every day
> on svn.apache.org, are programmers, might have itches to scratch, already
>
you're on the PMC. Why don't you do the tag&roll. ?
On Sun, Aug 27, 2023 at 4:31 PM Joe Schaefer wrote:
> Seems like it’s been a year since the last release, which means it’s time
> for good people to take another try at releasing something nondefective.
>
> Here to help with the quality control
lease?
Cheers,
-g
[1] https://whimsy.apache.org/roster/committer/joes
On Mon, Aug 28, 2023 at 8:43 AM Joe Schaefer wrote:
> Because my account no longer exists?
>
> On Mon, Aug 28, 2023 at 1:43 AM Greg Stein wrote:
>
>> you're on the PMC. Why don't you do the tag&ro
count is made available
> somehow.
>
> On Mon, Aug 28, 2023 at 4:50 PM Greg Stein wrote:
>
>> Your LDAP record is still present [1]. You're still on the PMC of httpd
>> and perl. Commit rights to incubator, sis, subversion. Dunno where httpd
>> went, but as a PMC member
And we probably don't want that $Header$ in there, either.
I would think the Bison/flex output would be generated during buildconf
(rather than a Makefile) so that we don't have to expect users to generate
them at build time (meaning they would have to have Bison/flex).
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
et the key
> > >the postfix hook had set up.
apr_pool_userdata_get(&data, "ian-ssi-tag-data", r->pool);
>...
> > How about changing request_rec->notes to a hash table? This would be
> > a relatively simple change, as the notes field isn't used in a huge
> > number of places in the standard modules.
No need. IMO, r->notes should just go away. It is pointless nowadays.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
On Wed, Aug 22, 2001 at 10:38:44PM -0700, Brian Pane wrote:
> Greg Stein wrote:
>...
> >Yes there is. apr_pool_userdata_set(..., r->pool)
>...
> Using the "userdata" functions on r->pool as a replacement for a
> hash-based r->notes would be a mistake. The
On Thu, Aug 23, 2001 at 01:22:00AM -0700, Brian Pane wrote:
> Greg Stein wrote:
> >I would posit those operations are not needed. The notes or userdata are for
> >specific bits of information. It is not a simple collection that you can
> >iterate over. In fact, since you can
since everybody is
"oh no, it *MUST* be a beta" we're waiting forever. It's silly.
If you want a release, then make a release. Label it as beta or gold or
whatever later. Nobody said we can't change the quality level over time.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
On Thu, Aug 23, 2001 at 07:50:03AM -0500, William A. Rowe, Jr. wrote:
> From: "Greg Stein" <[EMAIL PROTECTED]>
> Sent: Thursday, August 23, 2001 2:37 AM
>
>
> > On Wed, Aug 22, 2001 at 10:38:44PM -0700, Brian Pane wrote:
> > > Gre
quot; :-)
I ran into this when somebody asked about writing a DAV server using CGI.
They never got the OPTIONS methods...
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
#x27;t realize libapr was now linked as a shared
> library. that explains everything.
You could probably pass --disable-shared at Apache's config line. Of course,
then *everything* would be built statically and you'd get a big ass blob of
an executable :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
t share a
> single apr_bucket_heap structure which points to str with a refcount of
> 2, rather than having two entirely separate apr_bucket/apr_bucket_heap
> pairs both of which point to str and each of which has a refcount of
> 1.
But that is the cooler solution :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Imagine if you have a particular protocol running over some socket to a
backend server. You know the next chunk of data is 1000 bytes. You insert
your custom socket bucket, saying " socket, 1000 bytes". It can be
read, but it can't be copied.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
ivate structure to something like
mod_filesystem. That mod_filesystem would implement the various translation
and other fs-related items that occur.
And no... I'm not suggesting this happen any time soon :-) But it will one
day, if I can figure out how to tackle it and can set aside the time.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
the system shared. Of
course, this also assumes that httpd-2.0/configure has the right set of
switches to prepare such a system.
But without the configure switches, you have no hope to do it anyways. So
you aren't even at a libtool problem yet.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
be a shared library. Should have been a long time ago, but we
didn't have installation running for it, so we made it a static library.
That was turned off recently, making things as they should be.
What are you blaming libtool for? Can you state the specific problem?
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
On Fri, Aug 24, 2001 at 08:27:57AM -0700, Ryan Bloom wrote:
> On Friday 24 August 2001 00:33, Greg Stein wrote:
> > On Fri, Aug 24, 2001 at 12:15:17AM -0700, Doug MacEachern wrote:
>...
> > > libuncooltool. i didn't realize libapr was now linked as a shared
>
hance to go back and
fix the stuff.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
est I can. Does
> the following patch look correct? If so, I'll commit.
The SSI stuff is a handler in 1.3, so it is the proper guy to state what is
handled. And it says "no POST" :-)
As a filter in 2.0, mod_include should just stay out of it.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
ext, b);
> }
> - r->allowed |= (AP_METHOD_BIT << M_GET);
> if (r->method_number != M_GET) {
I say the above lines should simply be removed.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
ame are both about translating URLs into the backend storage.
Why was this new one added? (did I miss some discussion somewhere?) And if
so, then why does translate_name stick around?
--
Greg Stein, http://www.lyra.org/
OM-METHOD)
Hmm... guess I should go read the original motivation for this, but it seems
that whatever the problem was, it should be solved differently.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
On Sun, Aug 26, 2001 at 05:15:54PM -0700, Ryan Bloom wrote:
> On Sunday 26 August 2001 17:16, Greg Stein wrote:
> > On Sun, Aug 26, 2001 at 11:06:55AM -0700, Marc Slemko wrote:
>...
> > > In 1.3, dependencies were generated periodically and then included in the
> > >
ut of memory.
Brian's recently posted patch looks good for this.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
dns_looked_up:1;
> -unsigned dns_resolved:1;
> +unsigned char dns_looked_up:1;
> +unsigned char dns_resolved:1;
>
> } uri_components;
Screw the bitfields. Just change all of them to plain old unsigned chars.
(and apr_byte_t in APR). There is no reason to be miserly with bits here.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
processor machine?
Cheers,
-g
p.s and yes, I know Ryan just applied it, but that doesn't mean it should
stay there :-)
--
Greg Stein, http://www.lyra.org/
On Tue, Aug 28, 2001 at 01:01:11PM -0700, Ryan Bloom wrote:
> On Tuesday 28 August 2001 12:17, Greg Stein wrote:
> > On Mon, Aug 27, 2001 at 05:09:01PM -0700, Aaron Bannert wrote:
> > > This patch implements a resource pool of context pools -- a queue of
>...
> > IOW,
On Wed, Aug 29, 2001 at 11:30:53AM -0700, Ryan Bloom wrote:
> The tarballs are up now! Let's get to beta this time,PLEASE
If it isn't beta quality, then release it as alpha.
But it should be released, no matter what.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
mbo as an alpha. Or we could get proxy
to work against the tagged-25 and then release the combo as beta.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
topper from making it beta, that's for sure.
No big deal. Let's release it as an alpha.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
appy.
+1
Cheers,
-g
(i.e. changing it to the hack that used to be there -- some kind of global
that each MPM had to deal with... that was ooky; this patch looks good)
--
Greg Stein, http://www.lyra.org/
Cleaning it is
not right.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
On Fri, Aug 31, 2001 at 09:16:15PM -0700, Ryan Bloom wrote:
> On Friday 31 August 2001 19:31, William A. Rowe, Jr. wrote:
> > From: "Greg Stein" <[EMAIL PROTECTED]>
> > Sent: Friday, August 31, 2001 9:30 PM
> >
> > > On Fri, Aug
od_gz in the core.
Please use -0.9 or something. It gets really confusing to see -1 and never
know what it means. As I've said before: -1 really ought to always mean a
veto. But... that's just me :-)
Needless to say, I'm +1 on the concept. It's a big win for everybody. I
haven't reviewed the code yet, so no commentary there.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
_vars_lazy(r, tag_val);
> +}
Two patterns of "apr_table_get, check for LAZY_VALUE, call
add_include_vars_lazy". I'd recommend a single "get_include_value()"
function to encapsulate this logic.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
s have a file like config.nice, so it doesn't apply.
Don't sweat your time. I've explained my reasons, Cliff and Justin seem to
agree quite wholeheartedly. And I'll repeat: -1 on anything rm'ing
config.nice
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
On Sun, Sep 02, 2001 at 12:15:33PM -0500, William A. Rowe, Jr. wrote:
> From: "Greg Stein" <[EMAIL PROTECTED]>
> Sent: Sunday, September 02, 2001 3:22 AM
>
> > I use distclean on my computer all the time. Along with extraclean. Neither
> > of those targets sh
e if the filter doesn't exist from a prior
> level).
>
> > None of this is addressing filter ordering across commands yet. I said 8 months
> > ago we've done an inadequte job of defining the use-filters syntax. I'm saying
> > the very same thing today.
>
> Yeah, I expect that the ordering of filter execution isn't going to be
> right given the code we have now. -- justin
--
Greg Stein, http://www.lyra.org/
module (probably a longer list, since some subprojects
> at a given time likely haven't gone gold just yet.)
I don't like your package/version names :-), but I completely agree with the
concept. It's what I advocated when we were discussing what to do about the
proxy stuff (and each time since).
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
d, I bet somebody
has already discovered that... :-)
> Committed. Thanks. -- justin
eek.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
hat you'll self-correct over time.
But if other people are being overly harsh, then you can tell them so.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
On Tue, Sep 04, 2001 at 08:15:08AM -0700, Ryan Bloom wrote:
> On Sunday 02 September 2001 01:22, Greg Stein wrote:
>...
> > I use distclean on my computer all the time. Along with extraclean. Neither
> > of those targets should toss config.nice. *That* is what I mean.
> >
ensure
that it is just as portable.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
re means -- that we have an obligation and responsibility to maintain it.
And we will. If it goes in.
Summary:
* zlib is not going to be included in any fashion, we'll use it by reference
if/when we need to
* you should release your 2.0 mod_gzip so that everybody can make an
informed decision about putting compression functionality into Apache
* if mod_gzip goes in, then it would do so earlier rather than later, and we
will deal with any API changes that occur between now and ship -- it isn't
your burden to bear, so there shouldn't be a reason to withold.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
e simply serving to make the filter system more
complicated.
> I'd like to commit something that is close
> to what Ian originally submitted and then tweak it slightly.
Push it back to him to tweak. It appears we have a bit of time :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
module contributions or inclusion
have a "lower bar" to become part of ASF-distributed bits? etc.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
be a GET as they are
> not duplicating the parent request's behaviour.
>
> --
> -eric
>
> ([EMAIL PROTECTED])
> Feel free to forward this message to any list for any purpose other than
> email address distribution.
--
Greg Stein, http://www.lyra.org/
On Wed, Sep 05, 2001 at 03:56:32AM -0400, [EMAIL PROTECTED] wrote:
> Greg Stein wrote...
>...
> > As stated elsewhere, pcre and expat are in there because they aren't
> > typically available, like zlib is.
>
> Ah... so that's the criteria? Ok.
Generally,
On Tue, Sep 04, 2001 at 11:56:48PM -0500, William A. Rowe, Jr. wrote:
>...
> You were discussing the possibility of parsing for
uld be constant, unless mod_gz introduces
some kind of caching.
> > * page resposne times are slower with GZ, but have a lower deviation
>
> The expectation is that the network bandwidth used should be much
> lower. The tradeoff is that the CPU should get nailed. -- justin
Also
> -if (strncmp(rnew->filename, fdir, fdirlen) == 0
> - && rnew->filename[fdirlen]
> - && ap_strchr_c(rnew->filename + fdirlen, '/') == NULL)
> +if (strncmp(rnew->filename, fdir, fdirlen) == 0 && rnew->filename[fdirlen])
> {
> char *udir = ap_make_dirstr_parent(rnew->pool, r->uri);
>
--
Greg Stein, http://www.lyra.org/
on different items, for different reasons. If you want a stable
server, with a sooner-than-later release, then concentrate on the core. Some
of those other people will work on modules which have *nothing* to do with
stability. If the core developers are distracted by mod_gz, then that is
their own fault, not the fault of introducing a new module.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
omething.
The more conspiratorial-minded of us would simply believe this whole thread
is to create a division and weaken the voting for mod_gz. Much like
politicians will introduce a second, similar bill to confuse and divide
supporters and then crush both bills. But of course that wouldn't
On Wed, Sep 05, 2001 at 09:15:56PM -0700, Ian Holsman wrote:
> Greg Stein wrote:
> >>On Wed, Sep 05, 2001 at 08:05:27PM -0700, Ian Holsman wrote:
> >>>Some performance results with mod_gz are available at
> >>>http://webperf.org/a2/v25/
> >>>(no co
On Wed, Sep 05, 2001 at 09:10:01PM -0700, Ian Holsman wrote:
> Cliff Woolley wrote:
> > On Wed, 5 Sep 2001, Greg Stein wrote:
> >>I don't understand what you're trying to solve here, and how this
> >>solves it.
> >
> > It's an attempt to
On Thu, Sep 06, 2001 at 08:54:58AM -0700, Doug MacEachern wrote:
> On Wed, 5 Sep 2001, Greg Stein wrote:
>
> > mod_gz is just a little bugger off to the side that the core people don't
> > have to truly worry about.
> ...
> > It can go in now and be fixed over ti
ant us to not do
> What's Right in this case simply because of the emotions
> that the debate caused.
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.
Current consensus
US file.
>
> By the way, consensus does not always mean unanimity. It also
> means general or majority agreement..
Right. That was my intent.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
ikes, a subproject can be
> created. This has been too long people, let's put 2.0 to bed.
Some people believe his veto is illegitimate -- that there is no technical
reason for vetoing the inclusion into modules/experimental.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
the browser. It is also completely
> ignoring the FLUSH bucket when it arrives and has no way to add
> 'Content-length:' if/when it is necessary.
All good points. There are also a bazillion other things that mod_gzip 1.x
does, which mod_gz can't do (and you've expla
ing. I'd like to see S3.5 implemented :-)
(I'm also psyched to try out decompression in Python's httplib module; if
zlib is present, then httplib could transparently decompress for the user)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
t week), so that we can do rollup releases. Once
we have that framework in place, then something like -extras could make
sense.
But any use of repositories outside of httpd-2.0 is going to simply make our
existing rollup problem even worse.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
'll be comitting the proxy
> module to it's placeholder in the core.
When you say placeholder, are you suggesting that you're going to commit the
code back into the httpd-2.0 branch?
Rather than doing that, why don't we work on the rollup mechanism instead?
Proxy has been m
As I explained to Kevin Kiley, having it in experimental *means* that
we can bother with it. It is really difficult to do that while it is a
patch being "maintained" by a single person.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
long in the core.
>
> In *your* opinion. Other people have different but equally valid
> opinions. No one person sets an absolute for the project.
Well, until they whip out their veto pen :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
e using
> .
> (Imagine if you protected this block with basic auth, but forgot
> that another URL can access the same directory.)
>
> If you wanted to add a "URLMapTo" directive that does something similar, I
> would be less opposed. But I still would not be in favour.
>
> Joshua.
--
Greg Stein, http://www.lyra.org/
tarball)
2) set it up *after* we establish the httpd-rollup subproject, so that we
have a consistent, easy work pattern for multiple/rollup releases
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
ciate a core version of it.
AP_CFG_MERGE_* located in http_config.h would make some sense to me.
In the mod_ssl version, there was the "unset" param; I would suggest the
simplest for assumes NULL. A second one would take an "unset" param.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
ome cases, not enough of this happens and the codebase
begins to show its creakiness. Adding comments, increasing consistency,
refactoring, etc.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
secmp strings??
Yah :-) It could be optimized by recording a flag in the request_rec,
stating that the filter was inserted (rather than looking for it). The
strcasecmp() shouldn't be necessary because we uppercase f->frec->name
nowadays.
Not that it will improve things overall, but there ya go. :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
t looks like we need to cut over to those extra four bytes
> across all platforms.
Oh, screw all that mess :-) Just use a UUID for the unique id. It has lots
of bits, and it is already unique (by definition and without work).
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
there,
too.
I'm +1 on creating httpd-rollup, and -0.5 on putting proxy back in.
[ if (since?) mod_ldap is going out, then we have to deal with the rollup
anyways, which would totally kill any impetus for putting proxy back in.
thus, I'm against bringing proxy back into the core. ]
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
installations use
> either one of these or the default location set by the layout.
> Not a problem, I think.
If the hard-coded default is never used, then why don't we just toss it, and
require people to pass/use a root?
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
PHP- or SSI-processed content.
With Subversion, we *only* have Location directives. There is absolutely
nothing on the disk to serve.
is an important directive and needs to be used in many, many
cases.
In this particular case, the problem arose because the attempt to set
"global" optio
On Thu, Sep 13, 2001 at 09:35:43AM -0700, dean gaudet wrote:
> On Tue, 11 Sep 2001, Greg Stein wrote:
>...
> > > Seems that we now have 64 bit cpu's with potentially 64 bit pids. This adds
> > > to the equation, it looks like we need to cut over to those extr
id();
> #else
> pid = getpid();
> #endif
>
> On the other side I saw that some other sources inside Apache use getpid(), is this
>not a problem there too? And if only Win32 has an insufficient getpid() definition,
>it may be enough to redefine this only there and leave all other as is...??
>
> Guenter.
--
Greg Stein, http://www.lyra.org/
Win32.)
For *Windows*, why bother? Use a UUID. You *know* it is unique.
For other platforms, the discussion could be longer, but I don't understand
why you would want to tie yourself in a knot when CoCreateGuid() is just
calling out to solve this.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
201 - 300 of 583 matches
Mail list logo
