Alex Karasulu wrote:
I thought about this a lot at one point and was compelled to add it.
The reason being the ability to request a normalized version of the
value without having to feed the attributeType into the normalize method.
Is there a place where we need to normalize a single value out of any
context ?
Or the need to ask the attribute to normalize the value on the value's
behalf since the attribute is what knows the attribute type and hence
has access to the normalizers.
If the attribute is asked to normalize a value, then it already knows
its attributeType. Then it's not really mandatory to store the AT into
the value because we already have access to the AT (except if you need a
normalizer with no parameter)
So this allows an attribute value to be normalized without requiring
direct access to the attribute type by the caller.
The main issue I have with this approach (feeding the value with the AT)
is that it requires more work when creating the attribute and the value :
- you have to pass the AT to all the instances
- you have to store this AT many times (not very memory light)
- you have to check that a value has the same AT than the attribute for
each new attribute
I'm not sure that it worth the price...
Also we are thinking about making some default implementations of
various interfaces like Entry, and Attribute act as factories for the
objects they contain. This way a value "belongs" to some
attributeType and attribute. If you don't have a reference to the
attributeType the only other way to have an argument free normalize()
method on the value is to have a back reference to the attribute the
value belongs to in the value. From there the attributeType can be
accessed and used to normalize without requiring the caller to provide
additional arguments like a norrmalizer or an attributeType.
It depends. We can have this normalize() method for entries and
attributes, but do we need it for values, instead of a value.normalize(
at ) ? The main pint is : do we manipulate value alone ? And if so, in
which context ?
At a high level in my mind an attribute value is closely associated
with an attributeType in terms of the way it is compared, returned and
set rather than with a specific attribute of a specific entry. This
decoupling can be exploited in indices on specific attributeTypes
which will contain the values of various entries.
Indices should work on the normalized form of the value. In this case,
there is no need to normalize the value again, without having access to
its attribute. I think that the current version of the server does not
work like this, as we are comparing not normalized values, doing the
normalization inside the comparison. If we change the way we compare
values by using normalized values instead, then this association ( value
<-> attributeType) suddenly lose a lot of interest.
I still have to think more about it. I'm not arguing with you, just
trying to see the light and push you a bit to see if I have missed
something important. Whoever is right is not important, because we win
in both case : if I'm right, we will have a better server, and if you
are right, I will have a better understanding of the server (and there
will be no way to improve the server in the direction I'm trying to take).
Thanks for the answers !
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
