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 >
