directory-api mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <>
Subject Re: Binary values and humanRedable flag
Date Mon, 10 Aug 2015 10:42:14 GMT
Le 10/08/15 11:47, Radovan Semancik a écrit :
> Hi,
> I'm not 100% sure about this, but it looks like that the API makes
> assumption that all human-readable values will be strings (e.g. in
> DefaultAttribute.add(...) method). I wonder whether this is correct.
> E.g. OpenLDAP and OpenDJ have this definition for jpegPhoto:
> attributeTypes: ( 0.9.2342.19200300.100.1.60 NAME 'jpegPhoto' DESC
> 'RFC2798: a
>   JPEG image' SYNTAX )
> There are is no explicit human readable flag, so the API parses this a
> humanReadable attribute syntax.

There is no flag that says an Attribute is H-R or not. The information
is provided in RFC 22524.3.2
<>. Syntax Object
> But then jpegPhoto is obviously binary. When I try to modify it with
> BinaryValue it ends up with:
> ERROR (o.a.d.api.ldap.model.entry.DefaultAttribute): ERR_04451 The
> value must be a String, as its AttributeType is H/R
> I'm doing the equivalent of attribute.add(new BinaryValue(bytes));

Hmmm... Do you have the full code as a test I can run on my machine ?

> Am I doing something wrong?
> And one related remark. The add( Value<?>... vals ) method in
> DefaultAttribute is not very convenient to use and still keep a good
> error reporting. E.g. in the above case it will not throw any error,
> just returns zero. This is enough to detect that there was an error
> (not very convenient though). But the reason why the attribute cannot
> be added is lost. I cannot report back to the higher layers anything
> better than "failed to add foo to bar". But the user will not know
> what was the reason.

Yes, that's true. the rational is that we do a best effort to inject
values correctly, converting them on the fly.

Note that this H-R flag itself is stupid. It was added 12 years ago as a
way to follow teh RFC, but as a matter of fact, the Syntax itself
already drives the type of data we can store in an Attribute. I made it
even more complex by trying to use Generics. Now, we have those
StringValue and BinaryValue all over the code.

Ideally, we should not have to care about what we store, and always
consider the stored values as byte[]. OTOH, it's not convenient when we
want to manipulate values as String, as converting them over and over
from byte[] to Strings is costly (epecially in the server). But I do
think we went way to far here. This conversion should be done internally
once, and that's it. It would save us a hell lot of time, and would make
the APi more comfortable to use.

I accept any better suggestio at this point !

View raw message