Another possible approach would be to create a new ap_meets_conditions_2() with resource_exists as an explicit argument ( instead of implicitly using r->notes ). Till the next major release we could just make the current ap_meets_conditions() call ap_meets_conditions_2() with resource_exists as 1. Later we can make ap_meets_conditions_2() the default ap_meets_conditions().
-Paritosh. p.s. This approach was proposed by Paul Querna when I had a little chat with him at apachecon. On 10/25/07, Paritosh Shah <[EMAIL PROTECTED]> wrote: > I had another look at ap_meets_conditions(), I guess what you say is > true. The current ap_meets_conditions() *does* assume resource exists > ( although it does not explicitly state that ). And in that case > NO_RESOURCE would indeed be more appropriate. > > - Paritosh. > > On 10/25/07, Chris Darroch <[EMAIL PROTECTED]> wrote: > > Paritosh Shah wrote: > > > > > There are really three states here ( wrt ap_meets_conditions()) > > > 1. resource exists > > > 2. resource does not exist > > > 3. nothing is known about existence of the resource > > > > > > Currently ap_meets_conditions() does not make any assumptions about > > > existance of the resource ( case 3 ). If we use a NO_RESOURCE flag > > > without addtional "Y" or "N" values, we can really only cover 2 states > > > ( flag is set and flag is not set ). In the case that flag is not set, > > > we cannot directly assume that the resource exists, because this runs > > > the risk of breaking a lot of existing modules which do not set any > > > flags. > > > > I don't think it's that complex (although of course I may be > > missing something). The current code assumes the resource exists. > > All that's needed, I believe, is a flag which, when present, indicates > > that the resource does not exist. We must continue to assume that > > the resource exists when the flag is not present, to avoid breaking > > things, so I don't see a need to add an explicit "yes, it exists" > > flag state -- that's just adding confusion, IMHO. > > > > > > In an ideal situation (maybe for httpd 3.0), we could have a flag > > like r->exists which must be set to either 0 or 1. But, since we > > want a backportable solution, we're looking at adding an optional > > flag to r->notes instead. > > > > Now, when that flag is not present, the code in ap_meets_conditions() > > must assume (as it does now) that the resource exists. That's the > > current behaviour, and it's correct for all cases except those where > > a module (like mod_dav) needs to indicate that the resource doesn't > > exist. So our flag is only going to be present at all in a few > > cases, which means there will be a degree of mystery to the code > > no matter how to slice the problem. > > > > If we use a flag named something like "RESOURCE_EXISTS", then > > what we care about is the case when that flag is set to "false", > > which means we've also got to have a "true" state as well. What I > > dislike about that is the code then has to assume that when the > > flag isn't present -- i.e., is undefined -- it should proceed as if > > the flag was set to the "true" state. > > > > But, that runs counter to a lot of other programmatic practice. > > A SQL expression like "WHERE foo = 1" will fail if foo is NULL, > > for example. Or in (non-strict) Perl, an undefined variable is treated > > as zero/false/empty/etc. by default. > > > > That's why I see a flag named something like "NON_EXTANT_RESOURCE" > > as a little better. It doesn't need to have true or false values; > > its presence alone indicates the opposite case from the default > > assumption. > > > > Anyway, I'll continue to think it over for a bit before I commit > > anything; please let me know if I've missed something! > > > > Chris. > > > > -- > > GPG Key ID: 366A375B > > GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B > > >
