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
