On 10/15/2015 01:14 AM, Emmanuel Lécharny wrote:
And in that case the "user provided" value is always binary, even for
string values.
The distinction between 'binary' and 'Strung' is a bit artificial, and
based on a flag that can be found in RFC 2252, the H-R flag :
The following table lists some of the syntaxes that have been defined
for LDAP thus far. The H-R column suggests whether a value in that
syntax would likely be a human readable string. Clients and servers
need not implement all the syntaxes listed here, and MAY implement
other syntaxes.
Yes. That's understood. But the fact that this distinction is artificial
might be yet another reason for StringValue and BinaryValue to have
almost the same behavior.
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.
That does not solve the problem of dealing with Value that have a String
Syntax (IA5String, DirectoryString, etc). We have to follow the rules
specified in RFC 4517 and RFC 4518.
Yes, you are right. But it will help if a BinaryValue gets (wrongly)
classified as StringValue in the schemaless mode. And that is a very
nice side-effect.
What is important here is that we
will have at some point to go from a byte[] representation to a String
format, because we need to be able to compara a vlaue with other values,
either to check if the candidate matches a filter, or to store the value
into an index. In other words, we must keep both a byte[] and a String
representation of a value...
Yes. I agree.
--
Radovan Semancik
Software Architect
evolveum.com
