directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <akaras...@apache.org>
Subject Re: [ServerEntry API] AttributeType into Values
Date Sun, 16 Dec 2007 17:55:42 GMT
Hi Emmanuel,

U make good points and u are right i have no idea where we will use
this normalize method on the value. I was just going on a gut feeling
that i have not quit rationalized yet. It may be completely
unnecessary.

Oh and BTW I don't think u r arguing :).  And as U say we all win in
the end no matter who is right.  I dreamed with delight at the thought
of someone like you, a true peer, to collaborate with since the first
line of code.  Do you think I would sensitize you or any one else from
free open discussion just to look like I am right?  Please don't worry
about me looking wrong when I am wrong all the time according to my
boss (my wife).

I see ur point about the PITA this can be from a code organization and
maintenance perspective even though the 4-byte overhead for the extra
AT reference does not worry me all that much.  BTW all indices use
normalized values only, other wise the server would crawl. But this
fact makes having the no arg normalize method less interesting as u
point out. We can just remove it for now if u like and add it or
something better if the need arises for direct normalization of
values.  I don't know if the need will ever arise but there is no
sense in you having to manage writing additional defensive code to
deal with it if we do not need to. If we are confronted with this need
it is only a few lines of code to readjust.

This also opens up another topic: what semanitics do we intend for
adding the values of one attribute to another attribute which
potentially can be of another AT? I am leaning towards only allowing
the addition of vales of an attribute foo to attribute bar if and only
if foo attribute is an instanceOf() the attributeType of bar. Hence
why I added this method in just recently.

It never ends :).

Alex

On 12/16/07, Emmanuel Lecharny <elecharny@gmail.com> wrote:
> 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
>
>
>

-- 
Sent from Gmail for mobile | mobile.google.com

Mime
View raw message