directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Radovan Semancik <radovan.seman...@evolveum.com>
Subject Re: Value handling ideas
Date Wed, 14 Oct 2015 19:26:53 GMT
Hi,

Sounds good. Just note that "user provided" value is in fact the one 
that is decoded from the protocol in case that a value is received in 
LDAP message. And in that case the "user provided" value is always 
binary, even for string values. If you remember our conversation some 
time ago the re-coding of string value by current implementation caused 
quite nasty problem if the receiver cannot reliably distinguish string 
and binary values. Therefore I really like the idea to store the 
original value and record on demand. If that is done well then the 
originally-received binary values can be retrieved even from StringValue 
class. And that will improve usability of the API.

-- 
Radovan Semancik
Software Architect
evolveum.com




On 10/12/2015 08:50 PM, Emmanuel L├ęcharny wrote:
> 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