You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Ben Hyde <bh...@pobox.com> on 1999/04/29 14:52:15 UTC
apr_ v.s. ap_
Ryan Bloom <rb...@raleigh.ibm.com> writes:
> > On Wed, Apr 28, 1999 at 05:12:06PM -0400, Ben Hyde wrote:
> > > Maybe it is a little late to say anything but I wish that apr_ was
> > > just ap_ in apr ...
> Why are we having this discussion again. We had it once already when we
> talk about all of the naming conventions. The general consensus was that
> types end in _t, enumerations end in _e, macros are capitalized, and
> everything begins with apr_ either caps or not depending on what it is.
If no one else feels this is a mistake then I will shut up. Since I
think is is just foolish self indulgence serves absolutely no useful
technical purpose and inflicts unnecessary noise into the the process
I couldn't let is pass without comment.
> ... By then, most if not
> all of the work in the 1.3 tree should have stopped, so keeping two
> repositories in sync is a non-issue.
The impression that 1.3.7 will be the last release in in that family
strikes me as wishful thinking. 2.0 is going to take time and inflict
a frightening API change on module authors. The interests of the
installed base will overwhelm any desire we might have to avoid
ongoing working 1.3.7. If we don't continue to evolve and maintain
1.3 others will. Just look at the scale of Ralf's EAPI patch as an
example.
Humm... I must be suffering from low blood sugar, sorry about that.
- ben
---
Must even the greatest visions of the heart be blurred by discretions?
-- Kathleen Scott
Re: apr_ v.s. ap_
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Ben Hyde wrote:
>
> The impression that 1.3.7 will be the last release in in that family
> strikes me as wishful thinking.
Well, I hope it'll be the last *feature* release, and that subsequent
1.3.* releases will be bug-fixes only. I hope. And no 1.4.
--
#ken P-)}
Ken Coar <http://Web.Golux.Com/coar/>
Apache Software Foundation <http://www.apache.org/>
"Apache Server for Dummies" <http://Web.Golux.Com/coar/ASFD/>
Re: apr_ v.s. ap_
Posted by Dean Gaudet <dg...@arctic.org>.
> > Names exported to the C linker by the APR project should be prefixed:
> >
> > [ ] apr_ [X] ap_ [ ] I don't care.
Re: apr_ v.s. ap_
Posted by Wilfredo Sanchez <ws...@apple.com>.
> Names exported to the C linker by the APR project should be prefixed:
>
> [ ] apr_ [X] ap_ [ ] I don't care.
-Fred
--
Wilfredo Sanchez, wsanchez@apple.com
Apple Computer, Inc., Core Operating Systems / BSD
1 Infinite Loop, 302-4K, Cupertino, CA 95014
Re: apr_ v.s. ap_
Posted by Greg Stein <gs...@lyra.org>.
> Names exported to the C linker by the APR project should be prefixed:
>
> [ ] apr_ [X] ap_ [ ] I don't care.
--
Greg Stein, http://www.lyra.org/
Re: apr_ v.s. ap_
Posted by Bill Stoddard <st...@raleigh.ibm.com>.
> Names exported to the C linker by the APR project should be prefixed:
>
> [x] apr_ [ ] ap_ [ ] I don't care.
>
> If less that six people vote we will leave it apr_.
>
> Voting begins: Mon May 3 12:00:00 PDT 1999
> Voting ends : Wed May 5 12:00:00 PDT 1999
--
Bill Stoddard
stoddard@raleigh.ibm.com
Re: apr_ v.s. ap_
Posted by Greg Stein <gs...@lyra.org>.
Greg Stein wrote:
>
> Ryan Bloom wrote:
> >...
> >... But the
> > argument for doing it is to get platform independance in Apache.
Oh, and on this one: how does using the apr_ prefix help here?
I think we can still get platform independence using the ap_ prefix. In
other words, I think your point here is bogus, too :-)
Uh oh... I think I'm getting punchy. Probably time for sleep :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: apr_ v.s. ap_
Posted by Greg Stein <gs...@lyra.org>.
Dean Gaudet wrote:
>
> On Tue, 4 May 1999, Greg Stein wrote:
>
> > Geez. Should we also rename the request_rec fields? Hey, why not... they
>
> Yes, I renamed request_rec fields in apache-nspr -- the ones which
> had semantic or access changes which weren't simple search and replace.
> That way the compiler could diagnose the problem.
Yes, fine, but you're taking my point out of context.
The point that I was making was *gratuitous* changes. Not changes that
will help you to diagnose errors.
The apr_ prefix is gratuitous, in my mind, as the functions should
retain the same semantics as before. If the signature changes (with or
without a corresponding semantic change), then the compiler will catch
it that way. No need to rename the function. If the semantics *do*
change, then a new function should be used.
I agree with Ben re: this is a huge cost to take now for a
low-probability benefit later.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: apr_ v.s. ap_
Posted by Dean Gaudet <dg...@arctic.org>.
On Tue, 4 May 1999, Greg Stein wrote:
> Geez. Should we also rename the request_rec fields? Hey, why not... they
Yes, I renamed request_rec fields in apache-nspr -- the ones which
had semantic or access changes which weren't simple search and replace.
That way the compiler could diagnose the problem.
Dean
Re: apr_ v.s. ap_
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Ryan Bloom wrote:
>
> Apahce and APR are different entities.
> They are currently coupled together, because APR is being developed with
> Apache in mind. I would hope, that APR will not stop being developed when
> it has everything Apache needs.
This has been prominent in my mind throughout, which is why I
vote for "apr_". (Although I was thinking of APR and Apache,
not APR and Apahce. ;-)
--
#ken P-)}
Ken Coar <http://Web.Golux.Com/coar/>
Apache Software Foundation <http://www.apache.org/>
"Apache Server for Dummies" <http://Web.Golux.Com/coar/ASFD/>
Re: apr_ v.s. ap_
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Ben Hyde wrote:
>
> Again this is a hypothetical future inconvenience cost
> compaired with a assured immediate high cost.
One is associated with design, and one with evolution.
> Denotational clarity is a good thing. I've no problem with
> buying it whenever change is forced by unavoidable reasons.
Ah, so don't design it that way, just fix it when it becomes
unavoidable.
> Are we going to make any attempt to to screw the module authors.
I assume you meant "not to" as opposed to "to to". Module
authors can tutu themselves without any assistance from me. :-)
Seriously..
Yes, I think attempts and efforts are going to be made.
Do you think it's a good idea to have a functionally
named routine keep the name even though the semantics have
changed between different versions of the API?
> > *shrug*
>
> Disinterest in the suffering of others is enivitable if there
> is nothing one can do about it.
You misunderstand my *shrug*. It did not denote disinterest,
but acknowledgment that the issue is a moot one.
> In a sense I'm pressing this issue because I think there is a
> questionable disinterest developing for the migration of the
> installed base.
And I'm resisting because it strikes me as potentially misplaced
conservatism. I'm willing to be convinced, but I haven't
seen an argument yet that does the trick.
--
#ken P-)}
Ken Coar <http://Web.Golux.Com/coar/>
Apache Software Foundation <http://www.apache.org/>
"Apache Server for Dummies" <http://Web.Golux.Com/coar/ASFD/>
Re: apr_ v.s. ap_
Posted by Ben Hyde <bh...@pobox.com>.
Rodent of Unusual Size <Ke...@Golux.Com> writes:
> Ben Hyde wrote:
> >
> > In what senario would APR introduce a name that collides with the
> > names used by its principle customer and sponser? That would be
> > bizzare.
>
> Mm. And how about someone who wrote a module for Apache,
> found functionality it liked, and assumed they were part of APR
> and portable outside of Apache? ap_find_token(), say, or
> perhaps ap_escape_html(), or possibly ap_os_canonical_filename()?
> Those would seem to perform httpd-neutral functions (from the
> names, at least), but they're (currently) part of Apache, not
> APR.
Again this is a hypothetical future inconvenience cost compaired with a
assured immediate high cost.
> You seem to be concerned about people having to do a
> s/ap_/apr_/g substitution and finding it painful;
Surely you don't mean to imply that is the magnitude of
this edit!
> I'm
> concerned about people being able to tell from looking at
> a function name whether it's Apache-only or usable elsewhere
> from the APR libraries.
Denotational clarity is a good thing. I've no problem with
buying it whenever change is forced by unavoidable reasons.
> Since most of the things going into
> the I/O layering portion of APR have different semantics
> than their 1.3 counterparts, all module ap_* function calls
> will need to be reviewed by module authors anyway.
This is really the root of the argument.
Are we going to make any attempt to to screw the module authors.
> *shrug*
Disinterest in the suffering of others is enivitable if there
is nothing one can do about it.
In a sense I'm pressing this issue because I think there is a
questionable disinterest developing for the migration of the
installed base.
Clearly Apache 2.0 will be more fun, if we don't worry about
that.
- ben
Re: apr_ v.s. ap_
Posted by un...@riverstyx.net.
Just my two bits... I'd much prefer for apr functions to be preceded by
apr_. I don't really have time to really follow all the developments, but
I do like playing with Apache when I have time, and I'm very interested in
playing with the APR, and it'd make my life (and I think, other
programmers lives) easier..
---
tani hosokawa
river styx internet
On Tue, 4 May 1999, Rodent of Unusual Size wrote:
> Ben Hyde wrote:
> >
> > In what senario would APR introduce a name that collides with the
> > names used by its principle customer and sponser? That would be
> > bizzare.
>
> Mm. And how about someone who wrote a module for Apache,
> found functionality it liked, and assumed they were part of APR
> and portable outside of Apache? ap_find_token(), say, or
> perhaps ap_escape_html(), or possibly ap_os_canonical_filename()?
> Those would seem to perform httpd-neutral functions (from the
> names, at least), but they're (currently) part of Apache, not
> APR.
>
> You seem to be concerned about people having to do a
> s/ap_/apr_/g substitution and finding it painful; I'm
> concerned about people being able to tell from looking at
> a function name whether it's Apache-only or usable elsewhere
> from the APR libraries. Since most of the things going into
> the I/O layering portion of APR have different semantics
> than their 1.3 counterparts, all module ap_* function calls
> will need to be reviewed by module authors anyway.
>
> *shrug*
> --
> #ken P-)}
>
> Ken Coar <http://Web.Golux.Com/coar/>
> Apache Software Foundation <http://www.apache.org/>
> "Apache Server for Dummies" <http://Web.Golux.Com/coar/ASFD/>
>
Re: apr_ v.s. ap_
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Ben Hyde wrote:
>
> In what senario would APR introduce a name that collides with the
> names used by its principle customer and sponser? That would be
> bizzare.
Mm. And how about someone who wrote a module for Apache,
found functionality it liked, and assumed they were part of APR
and portable outside of Apache? ap_find_token(), say, or
perhaps ap_escape_html(), or possibly ap_os_canonical_filename()?
Those would seem to perform httpd-neutral functions (from the
names, at least), but they're (currently) part of Apache, not
APR.
You seem to be concerned about people having to do a
s/ap_/apr_/g substitution and finding it painful; I'm
concerned about people being able to tell from looking at
a function name whether it's Apache-only or usable elsewhere
from the APR libraries. Since most of the things going into
the I/O layering portion of APR have different semantics
than their 1.3 counterparts, all module ap_* function calls
will need to be reviewed by module authors anyway.
*shrug*
--
#ken P-)}
Ken Coar <http://Web.Golux.Com/coar/>
Apache Software Foundation <http://www.apache.org/>
"Apache Server for Dummies" <http://Web.Golux.Com/coar/ASFD/>
Re: apr_ v.s. ap_
Posted by Ben Hyde <bh...@pobox.com>.
Ryan Bloom <rb...@raleigh.ibm.com> writes:
> How's this for an argument then. Apahce and APR are different entities.
> They are currently coupled together, because APR is being developed with
> Apache in mind. I would hope, that APR will not stop being developed when
> it has everything Apache needs.
No argument here, but if APR where to wander away from serving Apache's
needs Apache would fork and maintain it's own version. APR would, for
the forseeable future, bend over backward to avoid that happening.
> The goal of the ap_ and apr_ prefix is to avoid namespace collision.
> Currently, because they are being developed together, that namespace
> collision isn't happening. What happens in the future. I have no clue
> where APR could be in a year, does anybody?
In what senario would APR introduce a name that collides with the
names used by its principle customer and sponser? That would be
bizzare.
Your buying very expensive insurance today against an unlikely event
in the future.
> Are we willing to say that
> there will NEVER be any namespace collision between Apache and APR? That
> seems like a very strong statement.
That is what I'm saying, and it isn't a strong statement it's a statement
about how these two projects are peas in the same pod, friends, buddies.
> ap_ is the accepted apache way to name things. apr_ is currently the
> accepted apr way to name things. I just don't see a good reason to
> collapse them into one naming convention.
The reason is to prevent unnecessary change in Apache.
> I would rather use two
> different naming conventions, one for apache supplied functions and one
> for apr supplied functions, than take the cahnce that at some point in the
> future we have to rename all of the functions from one of the two
> projects.
I'd rather not, so we vote.
> Apache 2.0 seems like a reasonable place to make the change from using
> apr_ for platform independant functions that have NOTHING to do with a
> web server. Isn't that the key to this whole thing? Any ap_ function
> should be used in the running of a WEBSERVER, and a webserver only. Any
> apr_ function is a part of a library that is cross platform and is ready
> to be plugged into ANY project that needs it.
That is the current design. At what cost?
> To me, this division makes sense. The arguments below probably weren't
> clear enough, because I was reponding to a statement that sounded to me
> like "Lets not make our users change any of their code", and I was just
> pointing out that their code is going to change, regardless of whether we
> use ap_ or apr_ inside the apr library.
Is there any senario where you'd act to limit the costs inflicted on
users by these changes? Should the sanctity of the APR design ever
suffer in exchange for lower those costs? Do you have any concept
of the magnitude of these costs?
> The change from ap_ ro apr_ is not a gratiutous change. It is a reflect
> of us using a completely different library for some of our none webserver
> routines.
It's not gratiutious, it's cruel. If you had paying customers they
would just say "no way" and that would be that.
> One more argument here. Let's say in the future, we discover that apr
> isn't being developed any more, and there are features we need. But, NSPR
> is still being developed, and it is becoming the de facto standard for
> cross-paltform development. If Apache decides to use NSPR for it's next
> release, will we also argue with the Mozilla people that they need to
> change their names to begin with ap_? No, of course not, because it is a
> separate project. It seems to me, ANYTHING in the new library should have
> a completely different namespace, because it is a completely different
> project.
This class of argument just doesn't work for me. These are the "suffer
today for possible good tommorrow" arguments. The suffering today
is absolutely certian, the chance of tommorrow's benifit is almost zero.
> The changes themselves aren't too hard to make. Especially since the code
> hasn't gone out the door yet. I just think it is a mistake to tie APR to
> Apache too closely.
That it "hasn't gone out the door yet" makes if anything worse. It
only assures that a large community of people who will have to bear
the cost are not here to speak up.
> Ryan
- ben
Re: apr_ v.s. ap_
Posted by Ryan Bloom <rb...@raleigh.ibm.com>.
How's this for an argument then. Apahce and APR are different entities.
They are currently coupled together, because APR is being developed with
Apache in mind. I would hope, that APR will not stop being developed when
it has everything Apache needs.
The goal of the ap_ and apr_ prefix is to avoid namespace collision.
Currently, because they are being developed together, that namespace
collision isn't happening. What happens in the future. I have no clue
where APR could be in a year, does anybody? Are we willing to say that
there will NEVER be any namespace collision between Apache and APR? That
seems like a very strong statement.
ap_ is the accepted apache way to name things. apr_ is currently the
accepted apr way to name things. I just don't see a good reason to
collapse them into one naming convention. I would rather use two
different naming conventions, one for apache supplied functions and one
for apr supplied functions, than take the cahnce that at some point in the
future we have to rename all of the functions from one of the two
projects.
Apache 2.0 seems like a reasonable place to make the change from using
apr_ for platform independant functions that have NOTHING to do with a
web server. Isn't that the key to this whole thing? Any ap_ function
should be used in the running of a WEBSERVER, and a webserver only. Any
apr_ function is a part of a library that is cross platform and is ready
to be plugged into ANY project that needs it.
To me, this division makes sense. The arguments below probably weren't
clear enough, because I was reponding to a statement that sounded to me
like "Lets not make our users change any of their code", and I was just
pointing out that their code is going to change, regardless of whether we
use ap_ or apr_ inside the apr library.
The change from ap_ ro apr_ is not a gratiutous change. It is a reflect
of us using a completely different library for some of our none webserver
routines.
One more argument here. Let's say in the future, we discover that apr
isn't being developed any more, and there are features we need. But, NSPR
is still being developed, and it is becoming the de facto standard for
cross-paltform development. If Apache decides to use NSPR for it's next
release, will we also argue with the Mozilla people that they need to
change their names to begin with ap_? No, of course not, because it is a
separate project. It seems to me, ANYTHING in the new library should have
a completely different namespace, because it is a completely different
project.
The changes themselves aren't too hard to make. Especially since the code
hasn't gone out the door yet. I just think it is a mistake to tie APR to
Apache too closely.
Ryan
> You keep using that argument, and I keep thinking it is bogus.
>
> Yes, things will change, but why throw EVEN MORE changes at the person?
> Geez. Should we also rename the request_rec fields? Hey, why not... they
> have to recode their module anyhow. Oh... how about the #defines such as
> HTTP_METHOD_NOT_ALLOWED? Those should start with AP_, right? Let's
> change those, too! And OK, DONE, and DECLINED while we're at it!
>
> Of course those are silly, extreme suggestions, but it is an example of
> your logic taken to the next step.
>
> While people will need to change certain things about their modules, we
> should not gratuitously heap another bulk of changes on them just
> because we can.
>
> Cheers,
> -g
>
> --
> Greg Stein, http://www.lyra.org/
>
_______________________________________________________________________
Ryan Bloom rbb@raleigh.ibm.com
4205 S Miami Blvd
RTP, NC 27709 It's a beautiful sight to see good dancers
doing simple steps. It's a painful sight to
see beginners doing complicated patterns.
Re: apr_ v.s. ap_
Posted by Greg Stein <gs...@lyra.org>.
Ryan Bloom wrote:
>...
> On Mon, May 03, 1999 at 05:07:03PM -0400, Ben Hyde wrote:
> > ap_ is good because is reduces the amount we will have to redo
> > code in Apache and in all the down stream modules. I think you
> > have to have a pretty strong argument to force all that code to
> > change. I haven't heard a strong argument for this one.
>
> I would just like to remind everybody that ALL that code has to change
> anyway. There will be NO way that 1.3 modules will work with 2.0. This
> is because 1.3 uses int's as files and sockets, and 2.0 will be using
> apr_file_t and apr_socket_t types. Yes, downstream modules are going to
> take a hit, and so will all of the code in the base distribution. But the
> argument for doing it is to get platform independance in Apache.
You keep using that argument, and I keep thinking it is bogus.
Yes, things will change, but why throw EVEN MORE changes at the person?
Geez. Should we also rename the request_rec fields? Hey, why not... they
have to recode their module anyhow. Oh... how about the #defines such as
HTTP_METHOD_NOT_ALLOWED? Those should start with AP_, right? Let's
change those, too! And OK, DONE, and DECLINED while we're at it!
Of course those are silly, extreme suggestions, but it is an example of
your logic taken to the next step.
While people will need to change certain things about their modules, we
should not gratuitously heap another bulk of changes on them just
because we can.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: apr_ v.s. ap_
Posted by Ryan Bloom <rb...@raleigh.ibm.com>.
Sorry, I should pay more attention before I send the message. The vote
should have looked like
> [X] apr_ [ ] ap_ [ ] I don't care
:)
Ryan
On Tue, 4 May 1999, Ryan Bloom wrote:
> Names exported to the C linker by the APR project should be prefixed:
>
> [X] apr_ [ ] ap_ [X] I don't care
>
> On Mon, May 03, 1999 at 05:07:03PM -0400, Ben Hyde wrote:
> > ap_ is good because is reduces the amount we will have to redo
> > code in Apache and in all the down stream modules. I think you
> > have to have a pretty strong argument to force all that code to
> > change. I haven't heard a strong argument for this one.
>
> I would just like to remind everybody that ALL that code has to change
> anyway. There will be NO way that 1.3 modules will work with 2.0. This
> is because 1.3 uses int's as files and sockets, and 2.0 will be using
> apr_file_t and apr_socket_t types. Yes, downstream modules are going to
> take a hit, and so will all of the code in the base distribution. But the
> argument for doing it is to get platform independance in Apache.
>
> Ryan
>
> _______________________________________________________________________
> Ryan Bloom rbb@raleigh.ibm.com
> 4205 S Miami Blvd
> RTP, NC 27709 It's a beautiful sight to see good dancers
> doing simple steps. It's a painful sight to
> see beginners doing complicated patterns.
>
>
_______________________________________________________________________
Ryan Bloom rbb@raleigh.ibm.com
4205 S Miami Blvd
RTP, NC 27709 It's a beautiful sight to see good dancers
doing simple steps. It's a painful sight to
see beginners doing complicated patterns.
Re: apr_ v.s. ap_
Posted by Ryan Bloom <rb...@raleigh.ibm.com>.
Names exported to the C linker by the APR project should be prefixed:
[X] apr_ [ ] ap_ [X] I don't care
On Mon, May 03, 1999 at 05:07:03PM -0400, Ben Hyde wrote:
> ap_ is good because is reduces the amount we will have to redo
> code in Apache and in all the down stream modules. I think you
> have to have a pretty strong argument to force all that code to
> change. I haven't heard a strong argument for this one.
I would just like to remind everybody that ALL that code has to change
anyway. There will be NO way that 1.3 modules will work with 2.0. This
is because 1.3 uses int's as files and sockets, and 2.0 will be using
apr_file_t and apr_socket_t types. Yes, downstream modules are going to
take a hit, and so will all of the code in the base distribution. But the
argument for doing it is to get platform independance in Apache.
Ryan
_______________________________________________________________________
Ryan Bloom rbb@raleigh.ibm.com
4205 S Miami Blvd
RTP, NC 27709 It's a beautiful sight to see good dancers
doing simple steps. It's a painful sight to
see beginners doing complicated patterns.
Re: apr_ v.s. ap_
Posted by Manoj Kasichainula <ma...@raleigh.ibm.com>.
Names exported to the C linker by the APR project should be prefixed:
[ ] apr_ [ ] ap_ [X] I don't care
On Mon, May 03, 1999 at 05:07:03PM -0400, Ben Hyde wrote:
> ap_ is good because is reduces the amount we will have to redo
> code in Apache and in all the down stream modules. I think you
> have to have a pretty strong argument to force all that code to
> change. I haven't heard a strong argument for this one.
If we think we'll redo the API, and I've seen some rumblings of this,
then downstream modules are irrelevant (well, they will be covered by
an adapter module, I hope).
Re: apr_ v.s. ap_
Posted by Ben Hyde <bh...@pobox.com>.
Names exported to the C linker by the APR project should be prefixed:
[ ] apr_ [X] ap_ [ ] I don't care.
---
I will volunteer to do the edit to change it in the doc and the
sources.
ap_ is good because is reduces the amount we will have to redo
code in Apache and in all the down stream modules. I think you
have to have a pretty strong argument to force all that code to
change. I haven't heard a strong argument for this one.
In fact I consider it extremely cruel to expect all that code
to change for a coding convension that is mostly (only?) esthetic
in nature. When you vote not to change it please ask yourself
to what extent you trading the short term cost of this change
for the long term - and much larger distributed cost - of everybody
else changing their code.
The last time we underwent a significant name change it was hard,
tiresome, abrasive work. That time there was a technical necessity,
i.e. that Apache was colliding in the linker with third party
packages. (For example make_array.) This time around I see no
powerful argument.
It might be argued that a change from apr_ to ap_ is backtracking
on choices already made and decided. While I have some sympathy
for that now that I've started trying to use apr code I finding the
choice made isn't the right one. As APR comes back into the main
stream of Apache some backtracking seems inevitable.
- ben
Re: apr_ v.s. ap_
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Names exported to the C linker by the APR project should be prefixed:
[X] apr_ [ ] ap_ [ ] I don't care.
--
#ken P-)}
Ken Coar <http://Web.Golux.Com/coar/>
Apache Software Foundation <http://www.apache.org/>
"Apache Server for Dummies" <http://Web.Golux.Com/coar/ASFD/>
Re: apr_ v.s. ap_
Posted by Yitzchak Scott-Thoennes <st...@efn.org>.
In article <37...@Golux.Com>,
Rodent of Unusual Size <Ke...@Golux.Com> wrote:
>that module-writers on this list didn't realise they were entitled
>to vote (were they?) makes me think the decision might be 'erroneous.'
>From ABOUT_APACHE:
> Anyone on the mailing list can vote on a particular issue,
> but we only count those made by active members or people
> who are known to be experts on that part of the server.
My read of this is that anyone with an opinion is encouraged to vote, but
only in an advisory sense.
Re: apr_ v.s. ap_
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Ben Hyde wrote:
>
> > > Summary: ap_ over apr_ by 4 votes to 3, or 6 to 4 depending
> > > on how you count. - ben
>
> This would not have changed the outcome, unless
> of course I made other mistakes as well.
How not? Changing 4-3 to 4-4 isn't significant?
> This sounds like a motion to reconsider, for example:
> <http://www.wstandy.com/boosters/docs/rulesord/reconsider.htm>
>
> I'm not, today, a stickler for the details of these kinds of rules,
> but it would seem approprate to get "a member who voted with the
> prevailing side" to agree that this is a useful exercise, presumably
> because we need "to correct a hasty, ill-advised, or erroneous action,
> or to take into account added information or a changed situation that
> has developed since the taking of the vote."
Since I wasn't on the winning side, if we suddenly switch to these
rules I can't make such a motion. However, those rules also mention
passage by a 2/3 majority, which neither 4-4 nor 6-5 are.
I was definitely remiss in not raising this point before the ballot
deadline passed, and for that I apologise.
But if one of the arguments for/against this change is the
hardship imposed on module authors, then I think it's only
reasonable to get *their* responses rather than assuming we
know what they will be. That the vote was as close as it was,
the tally missed someone, and only allowed 48 hours makes me
think it counts as 'hasty;' that additional people who are possibly
entitled to vote (depending upon the hardship issue) have expressed
opinions after the vote makes me think we have 'added information;'
that module-writers on this list didn't realise they were entitled
to vote (were they?) makes me think the decision might be 'erroneous.'
If module-writer hardship is *not* one of the issues, I withdraw
all of these remarks. If no-one from the prevailing side wants
to revisit it, I won't object. I've cast my vote and expressed
my concerns, so now I'll shut up.
--
#ken P-)}
Ken Coar <http://Web.Golux.Com/coar/>
Apache Software Foundation <http://www.apache.org/>
"Apache Server for Dummies" <http://Web.Golux.Com/coar/ASFD/>
Re: apr_ v.s. ap_
Posted by Ben Hyde <bh...@pobox.com>.
Rodent of Unusual Size <Ke...@Golux.Com> writes:
> Ben Hyde wrote:
> >
> > Summary: ap_ over apr_ by 4 votes to 3, or 6 to 4 depending
> > on how you count. - ben
>
> You know, Ben, I think it would be only fair if you counted the
> one person whose part you've been championing: the module
> writer named "tani hosokawa", who voted for "apr_".
My apologies, I just swept thru the archive for instances of
the ballot. This would not have changed the outcome, unless
of course I made other mistakes as well.
> I would actually like to extend this ballot a bit, time-wise,
> and ask it on the apache-modules list as well, making it
> clear both here and there that this isn't a insiders-only
> vote and that *everyone* who might be affected is free to
> vote.
Some nice people recently gave me a copy of Robert's Rules
of Order. I've been entertaining my self at dinner by asking
my children what they think the book ought to say about various
senarios.
This sounds like a motion to reconsider, for example:
<http://www.wstandy.com/boosters/docs/rulesord/reconsider.htm>
I'm not, today, a stickler for the details of these kinds of rules,
but it would seem approprate to get "a member who voted with the
prevailing side" to agree that this is a useful exercise, presumably
because we need "to correct a hasty, ill-advised, or erroneous action,
or to take into account added information or a changed situation that
has developed since the taking of the vote."
- ben
Re: apr_ v.s. ap_
Posted by Greg Stein <gs...@lyra.org>.
Rodent of Unusual Size wrote:
>
> Ben Hyde wrote:
> >
> > Summary: ap_ over apr_ by 4 votes to 3, or 6 to 4 depending
> > on how you count. - ben
>
> You know, Ben, I think it would be only fair if you counted the
> one person whose part you've been championing: the module
> writer named "tani hosokawa", who voted for "apr_".
I am also a module writer and I voted for "ap_". So it isn't just "one
person" ... In fact, some of the other Apache members may also be voting
with an eye towards the modules they maintain.
IMO, the issue seems closed. We had a full round of voting, it has
trailed off, and Ben tallied the votes.
It is quite conceivable the apache-modules list is not as aware of the
issues, tradeoffs, or other aspects of the situation. I certainly see a
different level of familiarity with the Apache interface on that list. I
am not wont to place a lot of opinion in any vote there.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: apr_ v.s. ap_
Posted by Dan Kegel <da...@alumni.caltech.edu>.
Rodent of Unusual Size wrote:
> I would actually like to extend this ballot a bit, time-wise,
> and ask it on the apache-modules list as well, making it
> clear both here and there that this isn't a insiders-only
> vote and that *everyone* who might be affected is free to
> vote.
I refrained from voting because I haven't touched the code
myself, but my two bits would be for apr_ if I knew what
I was talking about :-)
- Dan
Re: apr_ v.s. ap_
Posted by Ryan Bloom <rb...@raleigh.ibm.com>.
> It would be great to have apr_thread_, apr_io_, apr_mutex_ prefixes
> ( with the prefix acting as a "package name").
Although we do no use the apr_(package name) convention, IMHO, it is very
easy to determine which package is being referenced by the function. Most
of them have some reference to the package. i.e. ap(r)_procattr_*,
ap(r)_socket_create
>
> ( don't forget - there are 100+ functions, little documentation, and of
> course you know all of them, but for people with less experience it's not
> so easy, and at least apr_ was a help)
The documentation for the apr library functions is actually quite
complete. Everytime a function is written, it is fully documented, so
when an actual release is made, hopefully the documentation issue for apr
will go away.
Ryan
_______________________________________________________________________
Ryan Bloom rbb@raleigh.ibm.com
4205 S Miami Blvd
RTP, NC 27709 It's a beautiful sight to see good dancers
doing simple steps. It's a painful sight to
see beginners doing complicated patterns.
Re: apr_ v.s. ap_
Posted by un...@riverstyx.net.
Not to mention the impact it will have on the usability of apr. I
wouldn't want to be Joe Blow off the street trying to code me some APR and
having to keep checking my printouts of header files to remember which
style of prefix X function has. Reminds me of Sesame Street.
One of these things is not like the other, one of these things is not
quite the same...
apr_snprintf, apr_fnmatch, apr_validate_password, apr_MD5Encode,
apr_slack, ap_is_fnmatch, apr_killpage, apr_vformatter....
---
tani hosokawa
river styx internet
On Sat, 8 May 1999 costin@tdiinc.com wrote:
> >
> > I would actually like to extend this ballot a bit, time-wise,
> > and ask it on the apache-modules list as well, making it
> > clear both here and there that this isn't a insiders-only
> > vote and that *everyone* who might be affected is free to
> > vote.
>
> I really liked apr_ - it is much easier to find in what category a
> function belong.
> I all methods start with ap_ you loose 3 letters and get no info.
> With apr_ at least you split the 100+ functions in 2 categories.
>
> It would be great to have apr_thread_, apr_io_, apr_mutex_ prefixes
> ( with the prefix acting as a "package name").
>
> ( don't forget - there are 100+ functions, little documentation, and of
> course you know all of them, but for people with less experience it's not
> so easy, and at least apr_ was a help)
>
> Just my 2c.
> Regards,
> Costin
>
>
Re: apr_ v.s. ap_
Posted by co...@tdiinc.com.
>
> I would actually like to extend this ballot a bit, time-wise,
> and ask it on the apache-modules list as well, making it
> clear both here and there that this isn't a insiders-only
> vote and that *everyone* who might be affected is free to
> vote.
I really liked apr_ - it is much easier to find in what category a
function belong.
I all methods start with ap_ you loose 3 letters and get no info.
With apr_ at least you split the 100+ functions in 2 categories.
It would be great to have apr_thread_, apr_io_, apr_mutex_ prefixes
( with the prefix acting as a "package name").
( don't forget - there are 100+ functions, little documentation, and of
course you know all of them, but for people with less experience it's not
so easy, and at least apr_ was a help)
Just my 2c.
Regards,
Costin
RE: apr_ v.s. ap_
Posted by Randy Terbush <ra...@covalent.net>.
There are over 600 subscribers on apache-modules. Might be good to hit
them as well.
> -----Original Message-----
> From: new-httpd-owner@apache.org
> [mailto:new-httpd-owner@apache.org]On
> Behalf Of Rodent of Unusual Size
> Sent: Friday, May 07, 1999 9:51 AM
> To: new-httpd@apache.org
> Subject: Re: apr_ v.s. ap_
>
>
> Ben Hyde wrote:
> >
> > Summary: ap_ over apr_ by 4 votes to 3, or 6 to 4 depending
> > on how you count. - ben
>
> You know, Ben, I think it would be only fair if you counted the
> one person whose part you've been championing: the module
> writer named "tani hosokawa", who voted for "apr_".
>
> I would actually like to extend this ballot a bit, time-wise,
> and ask it on the apache-modules list as well, making it
> clear both here and there that this isn't a insiders-only
> vote and that *everyone* who might be affected is free to
> vote.
> --
> #ken P-)}
>
> Ken Coar <http://Web.Golux.Com/coar/>
> Apache Software Foundation <http://www.apache.org/>
> "Apache Server for Dummies" <http://Web.Golux.Com/coar/ASFD/>
>
Re: apr_ v.s. ap_
Posted by un...@riverstyx.net.
I think that's just more proof of why apr_ is a good idea. If it makes
code easier to read and it's a sed script to implement the changes, and in
light of the fact that pretty much no modules will be working once APR is
fully implemented, why not make us module writers go that one extra step?
Could even distribute a simple script in the source archive to do those
conversions. It's trivial, it's good for healthy codebases to have
cohesive names, ...
---
tani hosokawa
river styx internet
On Fri, 7 May 1999, Ryan Bloom wrote:
>
> I have made the changes to get apr_ functions renamed to ap_. I will wait
> on committing these changes until some time next week. Just as a quick
> FYI, it was a VERY simple thing to change. I ran one script twice in all
> of three directories. That was it. All the test programs worked
> properly. The only reason it took as long as it did, was that I messed up
> the command line once, and I had to re-extract, and start over. Teach me
> to keep a back-up before I do anything big like this. :)
>
> Ryan
>
> On Fri, 7 May 1999, Rodent of Unusual Size wrote:
>
> > Ben Hyde wrote:
> > >
> > > Summary: ap_ over apr_ by 4 votes to 3, or 6 to 4 depending
> > > on how you count. - ben
> >
> > You know, Ben, I think it would be only fair if you counted the
> > one person whose part you've been championing: the module
> > writer named "tani hosokawa", who voted for "apr_".
> >
> > I would actually like to extend this ballot a bit, time-wise,
> > and ask it on the apache-modules list as well, making it
> > clear both here and there that this isn't a insiders-only
> > vote and that *everyone* who might be affected is free to
> > vote.
> > --
> > #ken P-)}
> >
> > Ken Coar <http://Web.Golux.Com/coar/>
> > Apache Software Foundation <http://www.apache.org/>
> > "Apache Server for Dummies" <http://Web.Golux.Com/coar/ASFD/>
> >
>
> _______________________________________________________________________
> Ryan Bloom rbb@raleigh.ibm.com
> 4205 S Miami Blvd
> RTP, NC 27709 It's a beautiful sight to see good dancers
> doing simple steps. It's a painful sight to
> see beginners doing complicated patterns.
>
Re: apr_ v.s. ap_
Posted by Ryan Bloom <rb...@raleigh.ibm.com>.
I have made the changes to get apr_ functions renamed to ap_. I will wait
on committing these changes until some time next week. Just as a quick
FYI, it was a VERY simple thing to change. I ran one script twice in all
of three directories. That was it. All the test programs worked
properly. The only reason it took as long as it did, was that I messed up
the command line once, and I had to re-extract, and start over. Teach me
to keep a back-up before I do anything big like this. :)
Ryan
On Fri, 7 May 1999, Rodent of Unusual Size wrote:
> Ben Hyde wrote:
> >
> > Summary: ap_ over apr_ by 4 votes to 3, or 6 to 4 depending
> > on how you count. - ben
>
> You know, Ben, I think it would be only fair if you counted the
> one person whose part you've been championing: the module
> writer named "tani hosokawa", who voted for "apr_".
>
> I would actually like to extend this ballot a bit, time-wise,
> and ask it on the apache-modules list as well, making it
> clear both here and there that this isn't a insiders-only
> vote and that *everyone* who might be affected is free to
> vote.
> --
> #ken P-)}
>
> Ken Coar <http://Web.Golux.Com/coar/>
> Apache Software Foundation <http://www.apache.org/>
> "Apache Server for Dummies" <http://Web.Golux.Com/coar/ASFD/>
>
_______________________________________________________________________
Ryan Bloom rbb@raleigh.ibm.com
4205 S Miami Blvd
RTP, NC 27709 It's a beautiful sight to see good dancers
doing simple steps. It's a painful sight to
see beginners doing complicated patterns.
Re: apr_ v.s. ap_
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Ben Hyde wrote:
>
> Summary: ap_ over apr_ by 4 votes to 3, or 6 to 4 depending
> on how you count. - ben
You know, Ben, I think it would be only fair if you counted the
one person whose part you've been championing: the module
writer named "tani hosokawa", who voted for "apr_".
I would actually like to extend this ballot a bit, time-wise,
and ask it on the apache-modules list as well, making it
clear both here and there that this isn't a insiders-only
vote and that *everyone* who might be affected is free to
vote.
--
#ken P-)}
Ken Coar <http://Web.Golux.Com/coar/>
Apache Software Foundation <http://www.apache.org/>
"Apache Server for Dummies" <http://Web.Golux.Com/coar/ASFD/>
Re: apr_ v.s. ap_
Posted by Ryan Bloom <rb...@raleigh.ibm.com>.
On 6 May 1999, Ben Hyde wrote:
>
> Summary: ap_ over apr_ by 4 votes to 3, or 6 to 4 depending
> on how you count. - ben
Okay. Ben, I know you volunteered to make the changes, but I can do it
really easily today if you want me to. I have a script that will do this
work in a few minutes. And there are a few changes to names I would love
to do at the same time.
Just let me know.
Ryan
>
> ---
>
> Ben: Maybe it is a little late to say anything but I wish that apr_ was
> just ap_ in apr ...
> Ryan: Why are we having this discussion again. ...
> Ben: If no one else feels this is a mistake then I will shut up. ...
> Randy: I whole heartedly agree with your comments Ben. ...
> Ben: Ok, let's vote.
>
> Names exported to the C linker by the APR project should be prefixed:
>
> [ ] apr_ [ ] ap_ [ ] I don't care.
>
> If less that six people vote we will leave it apr_.
>
> Voting begins: Mon May 3 12:00:00 PDT 1999
> Voting ends : Wed May 5 12:00:00 PDT 1999
>
> Votes recieved:
>
> Brian:
> Mark:
> Lars:
> Roy:
> Alexei:
> Martin:
> BenL:
> Aram:
> Sameer:
> Cliff:
> Paul:
> Dirk:
> Bill: [x] apr_ [ ] ap_ [ ] I don't care.
> Ken: [X] apr_ [ ] ap_ [ ] I don't care.
> Jim: [X] apr_ [ ] ap_ [ ] I don't care.
> BenH: [ ] apr_ [X] ap_ [ ] I don't care.
> Dean: [ ] apr_ [X] ap_ [ ] I don't care.
> Ralf: [ ] apr_ [X] ap_ [ ] I don't care.
> Randy: [ ] apr_ [X] ap_ [ ] I don't care.
> 3 4 0 12(no ballot)
>
> Manoj: [ ] apr_ [ ] ap_ [X] I don't care
> Ryan: [X] apr_ [ ] ap_ [ ] I don't care
> Greg: [ ] apr_ [X] ap_ [ ] I don't care.
> Fred: [ ] apr_ [X] ap_ [ ] I don't care.
>
> 4 6 1
>
_______________________________________________________________________
Ryan Bloom rbb@raleigh.ibm.com
4205 S Miami Blvd
RTP, NC 27709 It's a beautiful sight to see good dancers
doing simple steps. It's a painful sight to
see beginners doing complicated patterns.
Re: apr_ v.s. ap_
Posted by Ben Hyde <bh...@pobox.com>.
Summary: ap_ over apr_ by 4 votes to 3, or 6 to 4 depending
on how you count. - ben
---
Ben: Maybe it is a little late to say anything but I wish that apr_ was
just ap_ in apr ...
Ryan: Why are we having this discussion again. ...
Ben: If no one else feels this is a mistake then I will shut up. ...
Randy: I whole heartedly agree with your comments Ben. ...
Ben: Ok, let's vote.
Names exported to the C linker by the APR project should be prefixed:
[ ] apr_ [ ] ap_ [ ] I don't care.
If less that six people vote we will leave it apr_.
Voting begins: Mon May 3 12:00:00 PDT 1999
Voting ends : Wed May 5 12:00:00 PDT 1999
Votes recieved:
Brian:
Mark:
Lars:
Roy:
Alexei:
Martin:
BenL:
Aram:
Sameer:
Cliff:
Paul:
Dirk:
Bill: [x] apr_ [ ] ap_ [ ] I don't care.
Ken: [X] apr_ [ ] ap_ [ ] I don't care.
Jim: [X] apr_ [ ] ap_ [ ] I don't care.
BenH: [ ] apr_ [X] ap_ [ ] I don't care.
Dean: [ ] apr_ [X] ap_ [ ] I don't care.
Ralf: [ ] apr_ [X] ap_ [ ] I don't care.
Randy: [ ] apr_ [X] ap_ [ ] I don't care.
3 4 0 12(no ballot)
Manoj: [ ] apr_ [ ] ap_ [X] I don't care
Ryan: [X] apr_ [ ] ap_ [ ] I don't care
Greg: [ ] apr_ [X] ap_ [ ] I don't care.
Fred: [ ] apr_ [X] ap_ [ ] I don't care.
4 6 1
RE: apr_ v.s. ap_
Posted by Randy Terbush <ra...@covalent.net>.
>
>
> Names exported to the C linker by the APR project should be
> prefixed:
>
> [ ] apr_ [X] ap_ [ ] I don't care.
>
> If less that six people vote we will leave it apr_.
>
> Voting begins: Mon May 3 12:00:00 PDT 1999
> Voting ends : Wed May 5 12:00:00 PDT 1999
>
If we truely want Apache to be a platform embraced by all, we need to
stop adding these gratuitous changes into the source tree. API changes
need to be given more serious weight than we have in the past.
Regarding the somewhat valid argument that APR will be standalone, it
seems that it serves our purposes better to start now with ap_ and if
some as yet undetermined application using APR in the future finds
some conflict with the ap_ namespace, can then provide some
compatibility conversion for APR (ie s/ap_/apr_/).
Re: apr_ v.s. ap_
Posted by Ben Hyde <bh...@pobox.com>.
Ben: Maybe it is a little late to say anything but I wish that apr_ was
just ap_ in apr ...
Ryan: Why are we having this discussion again. ...
Ben: If no one else feels this is a mistake then I will shut up. ...
Randy: I whole heartedly agree with your comments Ben. ...
Ok, let's vote. - ben
Names exported to the C linker by the APR project should be prefixed:
[ ] apr_ [ ] ap_ [ ] I don't care.
If less that six people vote we will leave it apr_.
Voting begins: Mon May 3 12:00:00 PDT 1999
Voting ends : Wed May 5 12:00:00 PDT 1999
RE: apr_ v.s. ap_
Posted by Randy Terbush <ra...@covalent.net>.
I whole heartedly agree with your comments Ben.
Anyone that thinks we should have another round of renaming, please
reread the archives surrounding the previous fiasco. There is no sense
in inflicting this kind of excercise on module developers.
> -----Original Message-----
> From: new-httpd-owner@apache.org
> [mailto:new-httpd-owner@apache.org]On
> Behalf Of Ben Hyde
> Sent: Thursday, April 29, 1999 7:52 AM
> To: new-httpd@apache.org
> Subject: apr_ v.s. ap_
>
>
> Ryan Bloom <rb...@raleigh.ibm.com> writes:
>
> > > On Wed, Apr 28, 1999 at 05:12:06PM -0400, Ben Hyde wrote:
> > > > Maybe it is a little late to say anything but I wish
> that apr_ was
> > > > just ap_ in apr ...
>
> > Why are we having this discussion again. We had it once
> already when we
> > talk about all of the naming conventions. The general
> consensus was that
> > types end in _t, enumerations end in _e, macros are
> capitalized, and
> > everything begins with apr_ either caps or not depending
> on what it is.
>
> If no one else feels this is a mistake then I will shut up. Since I
> think is is just foolish self indulgence serves absolutely
> no useful
> technical purpose and inflicts unnecessary noise into the
> the process
> I couldn't let is pass without comment.
>
> > ... By then, most if not
> > all of the work in the 1.3 tree should have stopped, so
> keeping two
> > repositories in sync is a non-issue.
>
> The impression that 1.3.7 will be the last release in in that family
> strikes me as wishful thinking. 2.0 is going to take time
> and inflict
> a frightening API change on module authors. The interests of the
> installed base will overwhelm any desire we might have to avoid
> ongoing working 1.3.7. If we don't continue to evolve and maintain
> 1.3 others will. Just look at the scale of Ralf's EAPI patch as an
> example.
>
> Humm... I must be suffering from low blood sugar, sorry about that.
>
> - ben
>
> ---
> Must even the greatest visions of the heart be blurred by
> discretions?
> -- Kathleen Scott
>