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 new API] Q about BasicServerAttribute
Date Fri, 14 Dec 2007 15:05:08 GMT
Meant to say server side verses client side here below sorry.

On Dec 14, 2007 10:04 AM, Alex Karasulu <akarasulu@apache.org> wrote:

> 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.
>
> Alex
>
>
>
> On Dec 14, 2007 6:57 AM, Emmanuel Lecharny < elecharny@gmail.com> 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
> > www.iktek.com
> > directory.apache.org
> >
> >
> >
>

Mime
View raw message