directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@gmail.com>
Subject Re: [ServerEntry new API] Q about BasicServerAttribute
Date Fri, 14 Dec 2007 15:53:17 GMT
Very valid points, Alex. We have had the same discussion a while back 
about DN parsing...

My personal guess is that you are almost fully right, but there might be 
cases where we may want to check some parts of the values. The H/R 
aspect, for instance, directly drives the type of value we will create. 
We can let the Schema intercerptor deal with normalization and syntax 
checking, instead of asking the EntryAttribute to do the checking. That 
means we _must_ put this interceptor very high in the chain.

Here are the possible checks we can have on a value for an attribute :
H/R : could be done when creating the attribute or adding some value into it
Syntax checking : SchemaInterceptor
Normalization : SchemaInterceptor
Single value : SchemaInterceptor

So I would say we should simply test the H/R flag in EntryAttribute.

It brings to my mind another concern :
let's think about what could happen if we change the schema : we will 
have to update all the existing Attributes, which is simply not 
possible. Thus, storing the AttributeType within the EntryAttribute does 
not sound good anymore. (unless we kill all the current requests before 
we change the schema). It would be better to store an accessor to the 
schema sub-system, no ?

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 
> 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.
Agreed, considering my first point is valid (see my previous comment)
>
> 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?
Pretty early, as you said. No need to transform a pretty well designed 
interceptor chain to a rigid system...
> 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.
That's not exactly what we want to introduce into the Entry class. This 
is clearly done by the Schema interceptor system. But it was not my 
initial concern, too, as I was specifically mentioning the 
EntryAttribute alone, not the Entry as a whole. So we are on the same 
page here.
> 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. 
yeah. We need some balance. This is the reason I asked before doing 
stupid things :) At the end, this will be less work  for me ;)
>
> 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.
Sure, a very pragmatic position I am found of. Thanks !
>
> Alex
>


-- 
--
cordialement, regards,
Emmanuel L├ęcharny
www.iktek.com
directory.apache.org



Mime
View raw message