Meant to say server side verses client side here below sorry.
On Dec 14, 2007 10:04 AM, Alex Karasulu <[EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]> 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
> >
> >
> >
>
