Le 03/10/2018 à 16:36, Radovan Semancik a écrit :
> On 10/03/2018 04:12 PM, Emmanuel Lécharny wrote:
>> I remember Alex reaction when he discovered those Decorator additions,
>> which was kind of "what the HECK is THAT ??? Ok, your choice, I'm not
>> going to touch it with a 10 feet pole..." (kind of. He may have been
>> less polite...)
>>
>> 6 or 7 years later (I don't exactly remember), the whole stuff seems to
>> me an insanity.
>
> I was wondering whether I was the only one that felt like that. Well, at
> least I know the answer now.
>
> Thanks for doing that. I applaud everything that makes the API simpler
> and more streamlined.
I forgot to mention that Decorators solve one problem : decoding is made
easier.
The thing is that when we decode a PDU, we get the pieces one after the
other. Typically, an AddRequest contains the entry DN, followed by all
the AttributeType and for each AttributeType, its values. We will get
something like :
0x68 LL
0x04 LL entry
0x30 LL attributesList
0x30 LL attributeList
0x04 LL attributeDescription
0x31 LL attributeValues
0x04 LL attributeValue
...
0x04 LL attributeValue
...
0x30 LL attributeList
0x04 LL attributeDescription
0x31 LL attributeValue
0x04 LL attributeValue
...
0x04 LL attributeValue
The way the decodr works is that it first creates an Entry (empty), then
add an AttributeType, keep a track of it, then add all the associated
values.
The problem is that The AddRequest implementation does not natively
support such additions : it contains an Entry. The Decorator was a nice
way to expose methods like setAttriuteType() or addValue().
But there are other means to do teh same thing, through the Entry
itself. It requires an indirection (always to a getEntry() before adding
a value or an AttributeType), that's all. Hopefully, the DefaultEntry is
not immutable... Well, it *should*, but we could also use the
ImmutableEntry constructor that gets a mutable DefaultEntry as a
parameter (note that the implementation is atrocious too : each modifier
method are written in a way to throw an exception...)
Anyway, don't expect a 12 years old effort to be perfect, especially as
it was developped in burst of activity here and there. And all in all,
it's not *THAT* bad, compared to JNDI ;-) We just need to adopt a CI/CD
process : Continuous Improvement/Continuous Development :-)
--
Emmanuel Lecharny
Symas.com
directory.apache.org
