Hallvard B Furuseth wrote:
Howard Chu writes:
I guess you're really describing something like floating-point representation, except our exponents are always positive.
A mixture and floating point and DER, I suppose. I've hardly looked inside a floting-point number for decades. Fixed length like you say and "exponent" = "length it would have if represented exactly", as with floating-point. But with a lenght-of-length component and counted in octets, not bits, as in DER. And I don't see much point in doing the base-10 multiplication or division needed for true floating point. Unless floating-point hardware is sufficiently magical nowadays that it's an advantage to make use of it. I don't have a clue myself.
I don't know if anyone uses huge enough integers in LDAP that it's a gain to avoid base10 conversion, but I don't know they don't either. Probably a bad idea now that I think of it, in case one later moves to an an LDAP/X.500-server with ASN.1 encoding, which will then have to convert between binary and decimal anyway.
Right, better to stick with binary.
Another point with huge integers is that one might store a group of them with small differences, and want an equality index to tell them apart. For that an index of <length, first digits, last digits> could be useful. Then the inequality index and inequality filter for a huge value would need to generate different index keys though. (The filter would need to replace the "last digits" part of huge values with 0x00... or 0xff...) I don't know if OpenLDAP's indexing supports that.
Schemes like that will always manage to go wrong. No matter what lengths you choose, you'll always have situations where the keys are in the wrong order. E.g., 0x99xx0088: <x,99,88> and 0x99xx0277: <x,99,77>
In any case, for similar reasons it might be an idea to keep supporting the old hash(decimal value) index format.
I tend to wonder if huge integers need to be accounted for here at all. I think it may be sufficient to just use <length, first N bytes> and probably N=4 is good enough.