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.
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.