directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel L├ęcharny <elecha...@gmail.com>
Subject Value handling ideas
Date Mon, 12 Oct 2015 18:50:55 GMT
Thoughts about value handling in the API and Server
---------------------------------------------------

We currently manage a quite complex hierarchy of classes to handle
attribute's values :

(Value<T>)
  o
  |
  +--[[AbstractValue<T>]]
        ^
        |
        +-- [StringValue | T : byte[]]
        |
        +-- [BinaryValue | T : String]
        
Every Value holds a wrappedValue (aka User Provided value) and a
normalizedValue. This second aspect is absolutely mandatory, because we
always return the UPValue back to the user, and we always compare values
using the normalized value (well, we can discuss that too).

DN and Filters are using a String representation of values that are a
bit specific. Typically, some chars get escaped in both cases (but not
the same way).

That is quite complex...

We probably can handle those values in a different way. First of all,
binary values aren't modified by the normalization process, so we could
most certainly save some space by not keeping a UpValue within a
NormValue for such values. Second, everything in LDAP is using UTF-8,
and we can easily convert UTF-8 to Unicode (which is the default format
for char in Java). We so have a trivial UTF-8 <--> Unicode conversion
that could be used if needed.

Last, not least every value is written either as a byte[] (binary
values) or as a UTF-8 String, which is also a byte[]. Knowing that we
will send back the values to the client converting them from String to
UTF-8, we can assume that most of the case, we are doing two conversions
(from byte[] to UTF-8 to String and then from String to UTF-8 to
byte[]), mostly wasting a lot of CPU...

Another idea would be to simply hide the byte[] unless we need to
convert them to a String, which can be done when needed. We need to
convert the values when we do a normalize (this happens when we want to
compare the value to another one), or a compare. We also need to run
every value through the PrepareString methods (and PrepSASL for the
userPassword) before saving them to the disk.


At this point, I can forsess some huge simplification in both the API
and the serverbu switching to a simpler data structure, and a potential
speedup (avoiding useless conversion).

I'd like you to review what I just wrote and tell me if I'm off base, or
if you feel like me that we can get a better server by changing those
data strcture.

Thanks !

Mime
View raw message