You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Stas Bekman <st...@stason.org> on 2004/09/18 01:54:10 UTC
renaming apr_filetype enum entries
As discussed back in June enum names in the apr_filetype_e entry are
polluting the APR_ defines namespace and it's hard to grok what APR_REG
means when it's used in the code. I've finally started to work on these as
I'm finishing the perl glue manpage for the apr_finfo interface.
So any objecttions to the s/APR_/APR_FILETYPE_/ rename?
In order to support older versions one will need to also provide a compat
layer:
#ifndef APR_FILETYPE_NOFILE
#define APR_FILETYPE_NOFILE APR_NOFILE
#endif
#ifndef APR_FILETYPE_REG
#define APR_FILETYPE_REG APR_REG
#endif
#ifndef APR_FILETYPE_DIR
#define APR_FILETYPE_DIR APR_DIR
#endif
#ifndef APR_FILETYPE_CHR
#define APR_FILETYPE_CHR APR_CHR
#endif
#ifndef APR_FILETYPE_BLK
#define APR_FILETYPE_BLK APR_BLK
#endif
#ifndef APR_FILETYPE_PIPE
#define APR_FILETYPE_PIPE APR_PIPE
#endif
#ifndef APR_FILETYPE_LNK
#define APR_FILETYPE_LNK APR_LNK
#endif
#ifndef APR_FILETYPE_SOCK
#define APR_FILETYPE_SOCK APR_SOCK
#endif
#ifndef APR_FILETYPE_UNKFILE
#define APR_FILETYPE_UNKFILE APR_UNKFILE
#endif
Any objections?
From what I understood, this should be applied only to the HEAD. Is that
correct?
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: renaming apr_filetype enum entries
Posted by Stas Bekman <st...@stason.org>.
Greg Stein wrote:
> On Sun, Sep 19, 2004 at 06:01:01PM -0400, Stas Bekman wrote:
>
>>Greg Stein wrote:
>>...
>>
>>>IMO, projects should just use the API of the oldest major revision that
>>>they can, and forget a bunch of compat stuff. If a project codes against
>>>version 1.0, then it will work for everything after that.
>>
>>mod_perl 2.0 needs to support apr 0.9.x (as long as 2.0.x requires it) and
>>it'll probably support 2.2 as well. So if those defines are added in apr
>>1.1 we can't use them w/o the compat layer, to support older libapr.
>
>
> That's what I'm saying: don't use them. Make your life easier and forget
> the compat layer. For some people, they'll go ahead and code to the new
> 1.1 API, and they'll use the better symbol names.
>
> But, your call. :-)
I've lost you Greg. Do you suggest not to use the new longer names? If so,
why do you think I'm trying to change them? If we expose the short names
then what's the point of all this mini-project?
>>>It will transparently work with both if we use APR_REG and friends. I
>>>don't want to add a bunch of #ifdef code to httpd if it isn't needed.
>>
>>Right, but there were just few opinions so far of whether both should be
>>supported or not. I just thought that the decision wasn't cast in stone yet.
>
>
> Both *WILL* be supported. There is no question to that. That's an absolute
> baesd on the compat rules. The only way to avoid supporting both is to
> shoot for a 2.0 release, and I'll veto any change that forces a 2.0 so
> darned soon. I would expect to live in 1.x land for at least a couple
> years. When our API gets too kludgy because of deprecation or whatever,
> *then* we move to 2.0 and clear that out.
+1
> I believe the only question on the table is whether the short form macros
> (e.g. APR_REG) are part of the API, or whether they are deprecated.
>
> But they *will* still exist.
understood.
>>>Well, what you're really doing is providing a 1.1 API to all users. I
>>>understand the motivation, but I'm not personally interested in that for
>>>httpd.
>>
>>You mean, you'd like to keep the old short defines used across httpd? and
>>inside libapr?
>
>
> Just in httpd. APR can use the new macros, of course.
OK, so now I'm asking whether the short macros should be deprecated (i.e.
whether the introduction of the new longer macros should be followed by a
replacement of the short ones across httpd and/or apr.
I understand that you are:
-1: replace in httpd
+0: replace in apr
correct?
what others think? so we can proceed with the change... thanks.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: renaming apr_filetype enum entries
Posted by Greg Stein <gs...@lyra.org>.
On Sun, Sep 19, 2004 at 06:01:01PM -0400, Stas Bekman wrote:
> Greg Stein wrote:
>...
> >IMO, projects should just use the API of the oldest major revision that
> >they can, and forget a bunch of compat stuff. If a project codes against
> >version 1.0, then it will work for everything after that.
>
> mod_perl 2.0 needs to support apr 0.9.x (as long as 2.0.x requires it) and
> it'll probably support 2.2 as well. So if those defines are added in apr
> 1.1 we can't use them w/o the compat layer, to support older libapr.
That's what I'm saying: don't use them. Make your life easier and forget
the compat layer. For some people, they'll go ahead and code to the new
1.1 API, and they'll use the better symbol names.
But, your call. :-)
>...
> >It will transparently work with both if we use APR_REG and friends. I
> >don't want to add a bunch of #ifdef code to httpd if it isn't needed.
>
> Right, but there were just few opinions so far of whether both should be
> supported or not. I just thought that the decision wasn't cast in stone yet.
Both *WILL* be supported. There is no question to that. That's an absolute
baesd on the compat rules. The only way to avoid supporting both is to
shoot for a 2.0 release, and I'll veto any change that forces a 2.0 so
darned soon. I would expect to live in 1.x land for at least a couple
years. When our API gets too kludgy because of deprecation or whatever,
*then* we move to 2.0 and clear that out.
I believe the only question on the table is whether the short form macros
(e.g. APR_REG) are part of the API, or whether they are deprecated.
But they *will* still exist.
>...
> >Well, what you're really doing is providing a 1.1 API to all users. I
> >understand the motivation, but I'm not personally interested in that for
> >httpd.
>
> You mean, you'd like to keep the old short defines used across httpd? and
> inside libapr?
Just in httpd. APR can use the new macros, of course.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: renaming apr_filetype enum entries
Posted by Stas Bekman <st...@stason.org>.
Greg Stein wrote:
> On Sun, Sep 19, 2004 at 05:20:59PM -0400, Stas Bekman wrote:
>
>>Greg Stein wrote:
>>...
>>
>>>And the #ifndef wrappers are not needed. Just define the old names in
>>>terms of the new.
>>
>>yes, yes, inside apr they won't be needed. They will be needed inside
>>projects supporting more than one apr generation.
>
>
> IMO, projects should just use the API of the oldest major revision that
> they can, and forget a bunch of compat stuff. If a project codes against
> version 1.0, then it will work for everything after that.
mod_perl 2.0 needs to support apr 0.9.x (as long as 2.0.x requires it) and
it'll probably support 2.2 as well. So if those defines are added in apr
1.1 we can't use them w/o the compat layer, to support older libapr.
>>>4) httpd 2.2 (and 2.1) will be able to work just fine with 1.1 without any
>>> recompilation being needed, but you may be fighting a battle against
>>> people distribution a 2.2/1.0 combo.
>>
>>But this can be solved inside 2.2 by adding the ifdef-define-endif future
>>compatibility blocks as I've posted in my original proposal. So 2.2 will
>>transparently work with apr 1.0 and apr 1.1.
>
>
> It will transparently work with both if we use APR_REG and friends. I
> don't want to add a bunch of #ifdef code to httpd if it isn't needed.
Right, but there were just few opinions so far of whether both should be
supported or not. I just thought that the decision wasn't cast in stone yet.
On the other hand if httpd/apr provide backward compatibility macros it's
almost the same as having both, if there is no deprecation cycle.
>>>Choose your path for mod_perl, but point #4 seems like it will pose
>>>trouble for your users.
>>
>>it doesn't have much to do with mod_perl, besides us trying to keep the
>>Perl API consistent with C API, so it's easy to move between the two,
>>needing to know only one API.
>
>
> Well, what you're really doing is providing a 1.1 API to all users. I
> understand the motivation, but I'm not personally interested in that for
> httpd.
You mean, you'd like to keep the old short defines used across httpd? and
inside libapr?
>>So if that's fine with everybody and now Bill has pulled down his veto,
>>the only thing to wait for is the APR_1_1 branch to appear? Any plans for
>>that?
>
>
> I'd like to see us move the APR modules over to SVN. We can then move the
> trunk to branches/1.0.x/, and leave the trunk for 1.1 development.
>
> I believe the last vote go-round had support for moving to SVN, so it was
> just a matter of "make it so". (I'd have to go look, and if anybody
> *doesn't* want to move to SVN, then please reiterate your concerns)
Sure, whatever it takes.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: renaming apr_filetype enum entries
Posted by Greg Stein <gs...@lyra.org>.
On Sun, Sep 19, 2004 at 05:20:59PM -0400, Stas Bekman wrote:
> Greg Stein wrote:
>...
> >And the #ifndef wrappers are not needed. Just define the old names in
> >terms of the new.
>
> yes, yes, inside apr they won't be needed. They will be needed inside
> projects supporting more than one apr generation.
IMO, projects should just use the API of the oldest major revision that
they can, and forget a bunch of compat stuff. If a project codes against
version 1.0, then it will work for everything after that.
>...
> >4) httpd 2.2 (and 2.1) will be able to work just fine with 1.1 without any
> > recompilation being needed, but you may be fighting a battle against
> > people distribution a 2.2/1.0 combo.
>
> But this can be solved inside 2.2 by adding the ifdef-define-endif future
> compatibility blocks as I've posted in my original proposal. So 2.2 will
> transparently work with apr 1.0 and apr 1.1.
It will transparently work with both if we use APR_REG and friends. I
don't want to add a bunch of #ifdef code to httpd if it isn't needed.
>...
> >Choose your path for mod_perl, but point #4 seems like it will pose
> >trouble for your users.
>
> it doesn't have much to do with mod_perl, besides us trying to keep the
> Perl API consistent with C API, so it's easy to move between the two,
> needing to know only one API.
Well, what you're really doing is providing a 1.1 API to all users. I
understand the motivation, but I'm not personally interested in that for
httpd.
> So if that's fine with everybody and now Bill has pulled down his veto,
> the only thing to wait for is the APR_1_1 branch to appear? Any plans for
> that?
I'd like to see us move the APR modules over to SVN. We can then move the
trunk to branches/1.0.x/, and leave the trunk for 1.1 development.
I believe the last vote go-round had support for moving to SVN, so it was
just a matter of "make it so". (I'd have to go look, and if anybody
*doesn't* want to move to SVN, then please reiterate your concerns)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: renaming apr_filetype enum entries
Posted by Greg Stein <gs...@lyra.org>.
On Sun, Sep 19, 2004 at 04:41:49PM -0500, William A. Rowe, Jr. wrote:
> At 04:20 PM 9/19/2004, Stas Bekman wrote:
> >So if that's fine with everybody and now Bill has pulled down his veto, the only thing to wait for is the APR_1_1 branch to appear? Any plans for that?
>
> APR_1_0 should be created soon, before new progress.
>
> HEAD should be 1_1 till we release it.
Know your tools, boys. We don't have to create a 1.0 branch right now.
Head can be 1.1. If we want 1.0 releases, *then* we create a branch. It is
easy to do that, based on the 1.0 tag. There is no need at all to hold any
development whatsoever.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: renaming apr_filetype enum entries
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 04:20 PM 9/19/2004, Stas Bekman wrote:
>So if that's fine with everybody and now Bill has pulled down his veto, the only thing to wait for is the APR_1_1 branch to appear? Any plans for that?
APR_1_0 should be created soon, before new progress.
HEAD should be 1_1 till we release it.
Re: renaming apr_filetype enum entries
Posted by Stas Bekman <st...@stason.org>.
Greg Stein wrote:
> On Fri, Sep 17, 2004 at 07:54:10PM -0400, Stas Bekman wrote:
>
>>As discussed back in June enum names in the apr_filetype_e entry are
>>polluting the APR_ defines namespace and it's hard to grok what APR_REG
>>means when it's used in the code. I've finally started to work on these as
>>I'm finishing the perl glue manpage for the apr_finfo interface.
>>
>>So any objecttions to the s/APR_/APR_FILETYPE_/ rename?
>>
>>In order to support older versions one will need to also provide a compat
>>layer:
>>
>>#ifndef APR_FILETYPE_NOFILE
>>#define APR_FILETYPE_NOFILE APR_NOFILE
>>#endif
>
>
> I think you have that backwards. Shouldn't it be:
>
> #define APR_NOFILE APR_FILETYPE_NOFILE
>
> i.e. the APR_FILETYPE_* macros are canonical and you're grandfathering the
> other macros
Right, Greg. I've just used these defines in mod_perl, before apr picks
those and for older versions as well. I meant these will be needed by
those projects that will want to use the longer name and will require to
support older libapr.
> And the #ifndef wrappers are not needed. Just define the old names in
> terms of the new.
yes, yes, inside apr they won't be needed. They will be needed inside
projects supporting more than one apr generation.
>>...
>>>From what I understood, this should be applied only to the HEAD. Is that
>>correct?
>
>
> Yes.
>
> wrowe commented on the versioning implications of this. To be precise:
>
> 1) the new symbolic constants would appear in 1.1
> 2) httpd 2.2 (and 2.1) is planned to be built against 1.0
> 3) if mod_perl uses the new names, it needs to be built against 1.1
it doesn't need to be built against 1.1, as we will provide the macros to
handle 0.9 - 1.1.
> 4) httpd 2.2 (and 2.1) will be able to work just fine with 1.1 without any
> recompilation being needed, but you may be fighting a battle against
> people distribution a 2.2/1.0 combo.
But this can be solved inside 2.2 by adding the ifdef-define-endif future
compatibility blocks as I've posted in my original proposal. So 2.2 will
transparently work with apr 1.0 and apr 1.1.
> 5) httpd 2.0 uses APR 0.9 (though it might be buildable against 1.0)
again, the same solution as #4 applies.
> Choose your path for mod_perl, but point #4 seems like it will pose
> trouble for your users.
it doesn't have much to do with mod_perl, besides us trying to keep the
Perl API consistent with C API, so it's easy to move between the two,
needing to know only one API.
So if that's fine with everybody and now Bill has pulled down his veto,
the only thing to wait for is the APR_1_1 branch to appear? Any plans for
that?
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: renaming apr_filetype enum entries
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Sep 17, 2004 at 07:54:10PM -0400, Stas Bekman wrote:
> As discussed back in June enum names in the apr_filetype_e entry are
> polluting the APR_ defines namespace and it's hard to grok what APR_REG
> means when it's used in the code. I've finally started to work on these as
> I'm finishing the perl glue manpage for the apr_finfo interface.
>
> So any objecttions to the s/APR_/APR_FILETYPE_/ rename?
>
> In order to support older versions one will need to also provide a compat
> layer:
>
> #ifndef APR_FILETYPE_NOFILE
> #define APR_FILETYPE_NOFILE APR_NOFILE
> #endif
I think you have that backwards. Shouldn't it be:
#define APR_NOFILE APR_FILETYPE_NOFILE
i.e. the APR_FILETYPE_* macros are canonical and you're grandfathering the
other macros
And the #ifndef wrappers are not needed. Just define the old names in
terms of the new.
>...
> From what I understood, this should be applied only to the HEAD. Is that
> correct?
Yes.
wrowe commented on the versioning implications of this. To be precise:
1) the new symbolic constants would appear in 1.1
2) httpd 2.2 (and 2.1) is planned to be built against 1.0
3) if mod_perl uses the new names, it needs to be built against 1.1
4) httpd 2.2 (and 2.1) will be able to work just fine with 1.1 without any
recompilation being needed, but you may be fighting a battle against
people distribution a 2.2/1.0 combo.
5) httpd 2.0 uses APR 0.9 (though it might be buildable against 1.0)
Choose your path for mod_perl, but point #4 seems like it will pose
trouble for your users.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: renaming apr_filetype enum entries
Posted by Max Bowsher <ma...@ukf.net>.
Stas Bekman wrote:
> Max Bowsher wrote:
>> Stas Bekman wrote:
>>> Well, we are about to freeze the mod_perl 2 API, and we would like to
>>> have
>>> non-ambiguous constants. So I'm not sure how to proceed from here.
>>
>>
>> Well, the APR_ namespace is non-ambiguously APR's, and APR itself can
>> ensure sanity within that namespace - what more is required?
>>
>> Personally, I think it's good that APR's constant names aren't
>> needlessly bloated in length.
>
> What's exactly APR itself? You mean it can look in the mirror and smile at
> how beautiful it is? And never leave the house?
>
> APR can be judged by how useful it is in the projects it's used. It's
> useless on its own.
I'm a little confused how the naming of these constants affects the
usefulness of APR in any way. Isn't this just a matter of stylistic
preference?
Max.
Re: renaming apr_filetype enum entries
Posted by Stas Bekman <st...@stason.org>.
Max Bowsher wrote:
> Stas Bekman wrote:
>
>> William A. Rowe, Jr. wrote:
>>
>>> At 09:05 PM 9/17/2004, William A. Rowe, Jr. wrote:
>>>
>>>> At 06:54 PM 9/17/2004, you wrote:
>>>>
>>>>
>>>>> So any objecttions to the s/APR_/APR_FILETYPE_/ rename?
>>>>
>>>>
>>>> Veto - defer for 2.0
>>>
>>>
>>>
>>> I don't object to the new names, but find it pretty absurd
>>> to start deprecating interfaces the month we roll out 1.0.
>>
>>
>> You mean, I've missed the train?
>>
>> Well, we are about to freeze the mod_perl 2 API, and we would like to
>> have
>> non-ambiguous constants. So I'm not sure how to proceed from here.
>
>
> Well, the APR_ namespace is non-ambiguously APR's, and APR itself can
> ensure sanity within that namespace - what more is required?
>
> Personally, I think it's good that APR's constant names aren't
> needlessly bloated in length.
What's exactly APR itself? You mean it can look in the mirror and smile at
how beautiful it is? And never leave the house?
APR can be judged by how useful it is in the projects it's used. It's
useless on its own.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: renaming apr_filetype enum entries
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 10:03 PM 9/17/2004, Max Bowsher wrote:
>Stas Bekman wrote:
>>William A. Rowe, Jr. wrote:
>>
>>>I don't object to the new names, but find it pretty absurd
>>>to start deprecating interfaces the month we roll out 1.0.
>>
>>You mean, I've missed the train?
>>
>>Well, we are about to freeze the mod_perl 2 API, and we would like to have
>>non-ambiguous constants. So I'm not sure how to proceed from here.
If you release mod_perl with those identifiers, you will be bound
to APR 1.1 - and httpd 2.1-dev is keyed to APR 1.0 at this time.
You must use APR 1.0 constants to be compatible with 2.2 when it's
released unless httpd adopts an APR 1.1.
Remember, new features get a minor version bump from now on, not
just another subversion bump.
See: http://apr.apache.org/versioning.html
>Well, the APR_ namespace is non-ambiguously APR's, and APR itself can ensure sanity within that namespace - what more is required?
Legibility is important too, so I've agreed with Stas,
in principal, with his renaming suggestions. Unfortuantely,
I didn't see enough other people comment about them to adopt
any of the proposed changes, for or against :(
>Personally, I think it's good that APR's constant names aren't needlessly bloated in length.
It's nice to have shorthand, and amusing that most Java developers
consider the terminal width to be 96 characters these days :)
I wouldn't consider the longhand needlessly bloated, however.
Bill
Re: renaming apr_filetype enum entries
Posted by Max Bowsher <ma...@ukf.net>.
Stas Bekman wrote:
> William A. Rowe, Jr. wrote:
>> At 09:05 PM 9/17/2004, William A. Rowe, Jr. wrote:
>>
>>> At 06:54 PM 9/17/2004, you wrote:
>>>
>>>
>>>> So any objecttions to the s/APR_/APR_FILETYPE_/ rename?
>>>
>>> Veto - defer for 2.0
>>
>>
>> I don't object to the new names, but find it pretty absurd
>> to start deprecating interfaces the month we roll out 1.0.
>
> You mean, I've missed the train?
>
> Well, we are about to freeze the mod_perl 2 API, and we would like to have
> non-ambiguous constants. So I'm not sure how to proceed from here.
Well, the APR_ namespace is non-ambiguously APR's, and APR itself can ensure
sanity within that namespace - what more is required?
Personally, I think it's good that APR's constant names aren't needlessly
bloated in length.
Max.
Re: renaming apr_filetype enum entries
Posted by Stas Bekman <st...@stason.org>.
William A. Rowe, Jr. wrote:
> At 09:05 PM 9/17/2004, William A. Rowe, Jr. wrote:
>
>>At 06:54 PM 9/17/2004, you wrote:
>>
>>
>>>So any objecttions to the s/APR_/APR_FILETYPE_/ rename?
>>
>>Veto - defer for 2.0
>
>
> I don't object to the new names, but find it pretty absurd
> to start deprecating interfaces the month we roll out 1.0.
You mean, I've missed the train?
Well, we are about to freeze the mod_perl 2 API, and we would like to have
non-ambiguous constants. So I'm not sure how to proceed from here.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: renaming apr_filetype enum entries
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 09:05 PM 9/17/2004, William A. Rowe, Jr. wrote:
>At 06:54 PM 9/17/2004, you wrote:
>
>>So any objecttions to the s/APR_/APR_FILETYPE_/ rename?
>
>Veto - defer for 2.0
I don't object to the new names, but find it pretty absurd
to start deprecating interfaces the month we roll out 1.0.
Bill