Le 15/10/15 13:46, Radovan Semancik a écrit : > 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 mean we should have one single class to handle values, then we are on teh same page. > >> >>> 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. IMO, we should stick to the Attribute Syntax that pretty much defines what can be done on a value. The distinction String/Binary is really not carrying enough information, and the fact that we have to fethc the Syntax is the proof we were wrong when creating those two classes. We have specific Normalizers and SyntaxCheckers for each of the AttributeTypes already... OTOH, from an history POV, the schema handling was quite in its infancy when we created this distinction :-) In any case, we have a lot to review in this area. Having re-checked the RFC 4517 and 4518, I realize I may have missed a few part of them when I tried to implement them years ago !
