Hi guys, I'm in the train back to Paris, where I have little to do but reading the RFCs (4514, 4518, 4512).
When I implemented the 'String Preparation' RFC (4518), I assumed it would save a hell lot of CPU to do it once and for all, and to store the result in the Values stored in the backend. The rational being that it's a costly operation, and there is no mean to do it over and over for Values we have already processed. The problem being that we are mixing two concepts here : normalization and string preparation. String preparation is intended to be used only when applying a matching rule. Normalization is the process of transforming a Value to something consistent, removing spurious spaces, using lower case if the AttributeType is case insensitive, etc. In the mean time, DN processing, especially conversion from ASN.1 to String and from String to DN requires a different processing, where we fist fragment the DN into AVAs, and then we normalize/prepare the values. Note that the two operations aren't exclusive : when comparing two DNs, we end with comparing values, thus string preparation is still required. Enters the filter processing (RFC 4515). Different escaping, still needing a string preparation. And there is a specific treatment for inner spaces i order to match some special filters (like cn=foo\20*\20bar). Now, we are in trouble... If we decide to desactivate the string preparation, to only apply it to any value we process when a matching rule is at play, we lose a lot of performance (OTOH, we gain a lot on every addition or update). If we decide to keep it, we have to review the way we use it, escpecially when processing DNs. The last nail in the cuffin : most of the time, we don't need to go through the prepare string operation on the client (except when comparing two values, something that is not frequently done), but we do it anyway because the client API and the server API is the same. I'll sleep on that and give you baxk some more thoughs in the next few days. Thanks !
