Re: minor MMN bump for 2.0
William A. Rowe, Jr. wrote: At 05:07 PM 2/26/2003, Greg Ames wrote: Sure. A handler which does its own apr_file_open looses the ability to use sendfile. Who cares? Only people who value performance. That's an APR implementation-dependent detail that you (the module/app author) has minimal control over. APR has nothing to do with how it works on Unix, other than being used as a parameter passing mechanism between the default_handler and the core_input_filter. Sure, APR comes into play on Win95, but I don't think there are a whole lot of people seriously trying to maximize Apache performance on Win95. Greg
Re: minor MMN bump for 2.0
At 05:07 PM 2/26/2003, Greg Ames wrote: >Sure. A handler which does its own apr_file_open looses the ability to use sendfile. Who cares? That's an APR implementation-dependent detail that you (the module/app author) has minimal control over. Bill
Re: minor MMN bump for 2.0
At 04:02 PM 2/26/2003, Greg Ames wrote: >I'd like to do a minor MMN bump in the 2.0 stable tree to account for the >apr_file_open interface changing via the addition of APR_ENABLE_SENDFILE. It's not a >huge deal unless you're a 3rd party module with a handler that needs all the >performance it can get, ala mod_specweb99. I'm not too concerned about the 2.1 tree; >we can just piggyback on to one of the other recent MMN changes there. > >Q. Shouldn't this really be a major bump? >A. Strictly speaking, yes. But that would cause more headaches than it would solve. > >Can I get some votes on this, please? It's absolutely not a major bump - that is - modules with or without the flags still *work*. We aren't breaking modules. Now if you flipped the bit definition that would be a bigger problem - but we already agreed that wouldn't happen - another flag would gain another new bit. In fact, I can't say that I see one reason to actually apply the bump. Running a module with the flag, on apr built at any point won't "break" the module. And APR isn't Apache. We shouldn't be bumping Apache, in any case, for this change. This is a change to APR (and I regularly cross two different APR and Apache versions for the best performance or the greatest reliability.) So I'd say no, no bump. We are about to tag 0.9.2 (or is that 0.9.3) in the next 24 hours to create a candidate. That APR version 0.9.2 (-gold) will tell you that your apr_file_open supports the new semantics. The hassle is that we've been using 0.9.2-dev and there is no way to distinguish the 'version' of apr between -dev and -gold. So I'm tempted to make this 0.9.3 and continue development on 0.9.3-dev till we are ready to call it 0.9.4. But that discussion is off-topic here ... snipping that bit for the apr list to continue the discussion there. Bill
Re: minor MMN bump for 2.0
Greg Ames wrote: Jeff Trawick wrote: > Regardless of a bump, it seems like the app is going to have to do > > #ifdef APR_ENABLE_SENDFILE > add in the flag > #endif > > unless they don't care what happens if they build it with 2.0.44. hey, that solves the whole thing, in both of the trees simultaneously! OK, we don't need a bump. I was thinking of: #if AP_MODULE_MAGIC_AT_LEAST(whatever) add in the flag #endif well, that's probably the cool way but it is too late to work properly (i.e., deal with 2.0.44)
Re: minor MMN bump for 2.0
Jeff Trawick wrote: Regardless of a bump, it seems like the app is going to have to do #ifdef APR_ENABLE_SENDFILE add in the flag #endif unless they don't care what happens if they build it with 2.0.44. hey, that solves the whole thing, in both of the trees simultaneously! OK, we don't need a bump. I was thinking of: #if AP_MODULE_MAGIC_AT_LEAST(whatever) add in the flag #endif u da man! Greg
Re: minor MMN bump for 2.0
Bill Stoddard wrote: Greg Ames wrote: I'd like to do a minor MMN bump in the 2.0 stable tree to account for the apr_file_open interface changing via the addition of APR_ENABLE_SENDFILE. It's not a huge deal unless you're a 3rd party module with a handler that needs all the performance it can get, ala mod_specweb99. I'm not too concerned about the 2.1 tree; we can just piggyback on to one of the other recent MMN changes there. Q. Shouldn't this really be a major bump? A. Strictly speaking, yes. But that would cause more headaches than it would solve. Why should this be a major bump? Is there any possible use of the API in 2.0.44 that would now be broken? Sure. A handler which does its own apr_file_open looses the ability to use sendfile. Greg
Re: minor MMN bump for 2.0
Greg Ames wrote: I'd like to do a minor MMN bump in the 2.0 stable tree to account for the apr_file_open interface changing via the addition of APR_ENABLE_SENDFILE. Regardless of a bump, it seems like the app is going to have to do #ifdef APR_ENABLE_SENDFILE add in the flag #endif unless they don't care what happens if they build it with 2.0.44.
Re: minor MMN bump for 2.0
Greg Ames wrote: I'd like to do a minor MMN bump in the 2.0 stable tree to account for the apr_file_open interface changing via the addition of APR_ENABLE_SENDFILE. It's not a huge deal unless you're a 3rd party module with a handler that needs all the performance it can get, ala mod_specweb99. I'm not too concerned about the 2.1 tree; we can just piggyback on to one of the other recent MMN changes there. Q. Shouldn't this really be a major bump? A. Strictly speaking, yes. But that would cause more headaches than it would solve. Why should this be a major bump? Is there any possible use of the API in 2.0.44 that would now be broken? Bill
minor MMN bump for 2.0
I'd like to do a minor MMN bump in the 2.0 stable tree to account for the apr_file_open interface changing via the addition of APR_ENABLE_SENDFILE. It's not a huge deal unless you're a 3rd party module with a handler that needs all the performance it can get, ala mod_specweb99. I'm not too concerned about the 2.1 tree; we can just piggyback on to one of the other recent MMN changes there. Q. Shouldn't this really be a major bump? A. Strictly speaking, yes. But that would cause more headaches than it would solve. Can I get some votes on this, please? Thanks, Greg
