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
