Joe Orton wrote:
On Tue, Dec 07, 2004 at 07:39:08PM -0500, Stas Bekman wrote:
Joe Orton wrote:
Well, since you really want feedback... ;) I often think this "naming
correctness" stuff goes too far, it just makes the API too verbose and
it can become unwieldy and ugly. Do you genuinely get confused
On Wed, Dec 08, 2004 at 10:36:56AM -0600, Jeff White wrote:
> From: "Joe Orton"
> >Well, since you really want feedback... ;) I often think this "naming
> >correctness" stuff goes too far, it just makes the API too verbose
> >and it can become unwieldy and ugly. Do you genuinely get confused
> >by
On Tue, Dec 07, 2004 at 07:39:08PM -0500, Stas Bekman wrote:
> Joe Orton wrote:
> >Well, since you really want feedback... ;) I often think this "naming
> >correctness" stuff goes too far, it just makes the API too verbose and
> >it can become unwieldy and ugly. Do you genuinely get confused by th
From: "Joe Orton"
Well, since you really want feedback... ;) I often think this
"naming
correctness" stuff goes too far, it just makes the API too verbose
and
it can become unwieldy and ugly. Do you genuinely get confused by
the
existing names?
Yes proper naming is very important
as it is now
Joe Orton wrote:
On Tue, Dec 07, 2004 at 01:07:05PM -0500, Stas Bekman wrote:
Anybody cares to followup? Since no one cares I'm not sure I should be
doing that.
Well, since you really want feedback... ;) I often think this "naming
correctness" stuff goes too far, it just makes the API too verbose
On Tue, Dec 07, 2004 at 01:07:05PM -0500, Stas Bekman wrote:
> Anybody cares to followup? Since no one cares I'm not sure I should be
> doing that.
Well, since you really want feedback... ;) I often think this "naming
correctness" stuff goes too far, it just makes the API too verbose and
it can b
Anybody cares to followup? Since no one cares I'm not sure I should be
doing that.
Stas Bekman wrote:
In view of 2), possibly 1) should be APR_FPROT_* ?
Yes, sorry, pasted it from the old proposal, here it is again:
Let me know if I should proceed with:
1) apr_file_permissions group:
APR_USETI
In view of 2), possibly 1) should be APR_FPROT_* ?
Yes, sorry, pasted it from the old proposal, here it is again:
Let me know if I should proceed with:
1) apr_file_permissions group:
APR_USETID => APR_FPROT_USETID
APR_UREAD => APR_FPROT_UREAD
etc.
2) APR_FILEPATH_* => APR_FPATH_* to be consi
Stas Bekman wrote:
William A. Rowe, Jr. wrote:
Now that 1.0.x is branched, svn is up and running and most
of the headaches are diminishing with the help of a bit
of advil...
I see no reason for Stas not to commit his APR_ file macro
renames on 1.1.x - it's commit-then-review so be my guest.
I've co
William A. Rowe, Jr. wrote:
Now that 1.0.x is branched, svn is up and running and most
of the headaches are diminishing with the help of a bit
of advil...
I see no reason for Stas not to commit his APR_ file macro
renames on 1.1.x - it's commit-then-review so be my guest.
I've committed to 1.1 the
Now that 1.0.x is branched, svn is up and running and most
of the headaches are diminishing with the help of a bit
of advil...
I see no reason for Stas not to commit his APR_ file macro
renames on 1.1.x - it's commit-then-review so be my guest.
Bill
At 05:07 PM 5/10/2002, Ryan Bloom wrote:
Symbol renames in APR are going to cause a problem for the web server.
Apache 2.0.36 is using the same major MMN as 2.0.35, but it isn't
compatible, because apr_explode_time was removed (as a single example,
there are more). We need to have some way t
Symbol renames in APR are going to cause a problem for the web server.
Apache 2.0.36 is using the same major MMN as 2.0.35, but it isn't
compatible, because apr_explode_time was removed (as a single example,
there are more). We need to have some way to fix these problems.
My opinion wou
13 matches
Mail list logo
