directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <>
Subject Re: [ServerEntry new API] Q about BasicServerAttribute
Date Fri, 14 Dec 2007 15:04:12 GMT
Hmmm good question.  I guess this leads to another question.  Should we
allow the user to create entries which have attribute values that are
syntactically incorrect?  And what does this do with respect to expected
behavior for this Server side attribute verses a user side analog?

Originally I liked this idea.  But after some time I started thinking this
is not such a good idea.  I think we should avoid adding too much
functionality into this.  Containment is the objective not syntax checking.
We simply need a minimal amount of schema checking to prevent certain
anomalies on the server side.  However we should leave this function to the
proper service whose role is explicitly dedicated towards fullfiling this
function which it centralizes while considering all aspects.  For example
schema checking will be done by parts of the schema service which must
consider a slew of aspects associated with this:

   o concurrent changes to schema during checks (aka locking)
   o configuration of schema checking: we might want to disable or relax
certain syntaxes
   o ...

The list goes on but I have to take off here.  I hope you see what I mean
here .. I don't want to have to be considering all these aspects and
duplicating such functionality here in the Entry/Attribute API which is
really there for composition of entries.

Further back on the issue of what users will expect in terms of behavior; we
will have a divergence in behavior from the client and server versions of
the API.  We already have some divergence but this will be wider in that it
will feel like the server is checking the user while things are being done.
Where do we stop with schema checks then? If the answer is apply all schema
checks then how do we deal with situations where the entry is inconsistent
during composition but will be consistent at the end?  For example you have
an inetOrgPerson that requires sn and cn attributes.  The user adds the
objectClass attribute with the inetOrgPerson value into the Entry.  If we
have schema checks enabled then this user action will trigger a violation
error.   Likewise if they add sn or cn before they add the objectClass
attribute since these attributes will not be in the must may list yet.  So I
think we open a Pandora's box if we try to overload too much functionality
into this Entry/Attribute API whose primary purpose is with respect to
managing entry composition.

I know we have to rely a bit on schema to do it right on the server side but
let's keep this to a minimum to avoid anomalies.


On Dec 14, 2007 6:57 AM, Emmanuel Lecharny <> wrote:

> Hi,
> just a quick Q :
> we have many methods 'add' in this class. Should we always check that
> the added value is syntaxically correct ? The current version does not
> check this :
>    public boolean add( String val )
>    {
>        return values.add( new ServerStringValue( attributeType, val ) );
>    }
> I suggest that we should write this method this way :
>    public boolean add( String val ) throws
> InvalidAttributeValueException, NamingException
>    {
>        if ( attributeType.getSyntax().isHumanReadable() )
>        {
>            attributeType.getSyntax().getSyntaxChecker().assertSyntax(
> val );
>            return values.add( new ServerStringValue( attributeType, val
> ) );
>        }
>        else
>        {
>            throw new InvalidAttributeValueException();
>        }
>    }
> wdyt ?
> --
> --
> cordialement, regards,
> Emmanuel L├ęcharny

View raw message