Rainer Jung wrote: > On 17.12.2009 23:14, William A. Rowe Jr. wrote: >> Rainer Jung wrote: >>> 1) Extending RewriteMap >>> ======================= >>> >>> I plan to extend key file handling in text file RewriteMap. At the >>> moment keys are always matched as exact strings against the map. I want >>> to add the ability to alternatively >>> >>> a) match via regexp (and replace backreferences in the found values) >>> b) match via ip network notation like e.g. used in "Require ip ..." >>> >>> This could be expressed in the configuration by adding another token >>> after type:source, e.g. "exact", "regexp", "ip", where "exact" is the >>> default. >> >> -1; you are going to completely hide the performance penalty from the >> user's attention. In order to identify this properly, please extend with >> an alternate directive to activate this (slower) mapping, e.g. >> RewriteList >> or some such. > > Really? The feature is off by default, users need to activate by adding > one of the new match types. Old configs will not see a performance penalty. > > The penalty when using the new match type can easily be documented the > same way I would need to documnt RewriteList. I'm not sure whether > adding a new directive is the way to go, because the purpose of the list > is the same as of the map. Only the type of key matching changes. I'm > afraid it will lead to some confusion.
Reviewers are more likely to catch a misconfig if you use RewriteList rather than some extra args. This is why I deprecated <Container ~ foo> so long ago, and replaced it with <ContainerMatch foo>. RewriteList's will take only a subset of the storage types, right? You aren't planning on using/reading large, nearly empty hash sets, are you?
