Re: renaming apr_filetype enum entries
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 BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: renaming apr_filetype enum entries
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
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
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
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
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 BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: renaming apr_filetype enum entries
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
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 BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
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_PIPEAPR_PIPE #endif #ifndef APR_FILETYPE_LNK #define APR_FILETYPE_LNK APR_LNK #endif #ifndef APR_FILETYPE_SOCK #define APR_FILETYPE_SOCKAPR_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 BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: renaming apr_filetype enum entries
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
Re: renaming apr_filetype enum entries
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 BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: renaming apr_filetype enum entries
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
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 BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: renaming apr_filetype enum entries
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