directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kiran Ayyagari <>
Subject Re: Value handling ideas
Date Tue, 13 Oct 2015 05:29:09 GMT
On Tue, Oct 13, 2015 at 2:50 AM, Emmanuel L├ęcharny <>

> 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...
> +1 to experiment with this change

> 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.
> but AFAIU this conversion happens multiple times if not stored, so I still
prefer converting once and use the stored value later onwards

> 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.
> changing the data structure idea sounds good to me

> Thanks !

Kiran Ayyagari

View raw message