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
|
