"William A. Rowe, Jr." wrote: > > > If we resolve the ->handler up front, why not > > > provide a ->handler_fn member that skips the entire handler() hook walk? > > > > The implementation would be interesting. Consider mod_dir and > > mod_autoindex. Both can deal with DIR_MAGIC_TYPE, and both could be > > present or absent. But when both are present, the handler topological > > sort rules must be respected so that handle_dir runs first. How do you > > propose dealing with that? And what about the few handlers that support > > fuzzy matches? > > Couple of bits. If we declare handler_fn identically to a hook_handler callback, > then we can maintain the semantics. A handler could raise it's hand, but later > DECLINE. If it DECLINEs, or handler_fn is NULL, then we proceed with the usual > walk. > > Second, autoindex should be a generator [handler]. mod_dir should _NOT_. I spelled > out the reasons for that on 2001.12.02.
OK, peace. But since we were talking about how to drive handlers more efficiently, we need to think about the harder cases. One of them will be how to deal with multiple handlers who will accept the same r->handler value. Greg
