Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 20842 invoked from network); 14 Dec 2007 15:05:50 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 14 Dec 2007 15:05:50 -0000 Received: (qmail 25704 invoked by uid 500); 14 Dec 2007 15:05:38 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 25661 invoked by uid 500); 14 Dec 2007 15:05:38 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 25650 invoked by uid 99); 14 Dec 2007 15:05:38 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 14 Dec 2007 07:05:38 -0800 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of akarasulu@gmail.com designates 64.233.184.232 as permitted sender) Received: from [64.233.184.232] (HELO wr-out-0506.google.com) (64.233.184.232) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 14 Dec 2007 15:05:14 +0000 Received: by wr-out-0506.google.com with SMTP id c49so790758wra.1 for ; Fri, 14 Dec 2007 07:05:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth; bh=CC5jqZ0fxxGMMSBcKkOXrmgr5eJotcpA8shAqdumORc=; b=nf+HZwftAWHP/XiHwSoI8NMwu8PbkuqlJxZ2FYQf1Zstb73WzkBwLS15y+zxmMS1i2hE/SWeKRf16kRdB3QiZiwkUGLcHvT4sr70TU9gmrCLYUASxsfGnY3YrwAFyGwkAs6XWbxJ8EMdLXBe7f3CFVdw0xLNoxjJBC+WZxG+MTU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=H9GYOtHgs3/IIMa8/QCYkvIfWWKCwRxHlL+M2G9tMD6boNcWKZtwtGXkeVu3IL6Xn1FKLj4ezR1rNJgMdsCZr3RgMKZkuoqVtd0+gMT7hEjozIugfKiCXGuU34A9Fcn5Wo+ccFJ3MhYN/aUqF8u/PIj6P09xy66MeFSAdV6QU7U= Received: by 10.143.187.2 with SMTP id o2mr1503473wfp.162.1197644708791; Fri, 14 Dec 2007 07:05:08 -0800 (PST) Received: by 10.143.166.2 with HTTP; Fri, 14 Dec 2007 07:05:08 -0800 (PST) Message-ID: Date: Fri, 14 Dec 2007 10:05:08 -0500 From: "Alex Karasulu" Sender: akarasulu@gmail.com To: "Apache Directory Developers List" Subject: Re: [ServerEntry new API] Q about BasicServerAttribute In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1661_11567174.1197644708722" References: <47626F97.6040402@gmail.com> X-Google-Sender-Auth: afda036226becd71 X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_1661_11567174.1197644708722 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Meant to say server side verses client side here below sorry. On Dec 14, 2007 10:04 AM, Alex Karasulu 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 thi= s > is not such a good idea. I think we should avoid adding too much > functionality into this. Containment is the objective not syntax checkin= g. > We simply need a minimal amount of schema checking to prevent certain > anomalies on the server side. However we should leave this function to t= he > 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 don= e. > Where do we stop with schema checks then? If the answer is apply all sche= ma > checks then how do we deal with situations where the entry is inconsisten= t > during composition but will be consistent at the end? For example you ha= ve > 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. S= o I > think we open a Pandora's box if we try to overload too much functionalit= y > 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=E9charny > > www.iktek.com > > directory.apache.org > > > > > > > ------=_Part_1661_11567174.1197644708722 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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.  Sho= uld we allow the user to create entries which have attribute values that ar= e syntactically incorrect?  And what does this do with respect to expe= cted behavior for this Server side attribute verses a user side analog?

Originally I liked this idea.  But after some time I started t= hinking this is not such a good idea.  I think we should avoid adding = too much functionality into this.  Containment is the objective not sy= ntax 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 tow= ards fullfiling this function which it centralizes while considering all as= pects.  For example schema checking will be done by parts of the schem= a service which must consider a slew of aspects associated with this:

   o concurrent changes to schema during checks (aka lock= ing)
   o configuration of schema checking: we might want to d= isable or relax certain syntaxes
   o ...

The list goe= s 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 duplicatin= g 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 beh= avior; we will have a divergence in behavior from the client and server ver= sions of the API.  We already have some divergence but this will be wi= der 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 answ= er 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 attri= butes.  The user adds the objectClass attribute with the inetOrgPerson= value into the Entry.  If we have schema checks enabled then this use= r action will trigger a violation error.   Likewise if they add s= n or cn before they add the objectClass attribute since these attributes wi= ll 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/Attribut= e API whose primary purpose is with respect to managing entry composition.&= nbsp;=20

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

&nb= sp;
 
On Dec 14, 2007 6:57 AM, Emmanuel Lech= arny < elecharny@gmail.co= m> 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 v= al )
   {
       return values.add( new Serve= rStringValue( attributeType, val ) );
   }

I suggest t= hat we should write this method this way :

   public bool= ean add( String val ) throws
InvalidAttributeValueException, NamingExcep= tion
   {
       if ( attributeType.getSy= ntax().isHumanReadable() )
       {
  &nbs= p;        attributeType.getSyntax().getSyntaxChecker().= assertSyntax(
val );

           re= turn values.add( new ServerStringValue( attributeType, val
) );
       }
       el= se
       {
          =  throw new InvalidAttributeValueException();
      =  }
   }

wdyt ?

--
--
cordialement, regards,
Emmanuel L=E9charny
www.iktek.comdirectory.apache= .org




------=_Part_1661_11567174.1197644708722--