granted, having two names for the same thing is confusing, especially in Perl-land where we access both through $r, but I like the way it turned out - $r->ap_auth_type represents the actual name of the request_rec slot, while $r->auth_type represents the function, and it's common to strip the ap_ prefix from functions when we port them to mod_perl.
IMHO, that's too confusing. May be we should have $r->per_dir_config->auth_type and $r->auth_type?
yeah, it is confusing. but it's not my fault - I'm sure there is a good reason why the folks over in core thought it was ok to have a function called ap_auth_type and a slot in the request_rec called ap_auth_type.
however, the more I look at things, the more I like the way it turned out. with my patch set...
- $r->auth_type means the same thing in 1.0 and 2.0 (it accesses the
configured AuthType directive for the current request)
- $r->ap_auth_type matches the associated slot in the request_rec by name, just like $r->assbackwards and $r->user
- $r->ap_auth_type is autogenerated, so we don't have to support additional code for it's access
- migration of authentication code from 1.0 to 2.0 is as simple as "$r->connection->user is now $r->ap_auth_type" (and possibly a patch in 1.0 to ease migration, similar to how $r->user is an alias in 1.0)
the only other option is probably what you say and what I brought up before - use $r->per_dir_config->auth_type. but I think that has the chance to be equally misleading - we should be using the ap_auth_type() function for access to AuthType, and $r->per_dir_config->auth_type suggests (or really is) accessing the per_dir_config structure directly.
of course, if you go with $r->per_dir_config->auth_type then that means that $r->auth_type is really accessing r->ap_auth_type, which is _really_ confusing if you think about 1.0 portability, where $r->auth_type is _completely_ different between 1.0 and 2.0.
so, all in all, I don't think it's so bad the way I've set it up. my suggested change has minimal impact on those using the API already, and for those being introduced to it things sorta fall into place (if you think in terms of the request_rec). the only place it will likely get confusing is for we hard-core Apache types, who never expect to see ap_ in a method call, but in that case it even makes sense - since we never include ap_ in a method, it must be something else (like a real name in the request_rec, go figure).
anyway, I guess I'm saying that I'm comfortable with it, it works, it involves the least number of changes for both core and end users, and it's the least confusing option in a very confusing situation.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
