On Apr 22, 2010, at 2:58 PM, Michael Str=F6der wrote:
Kurt Zeilenga wrote:
One additional note, I generally would advise that a schema-aware =
client
not alter it's update behavior of elements based upon whether said =
elements
are active or inactive (OBSOLETE) in the schema.=20
=20 I disagree especially for cases when new data is added.
I think you're trying to make the client far smarter than it really = ought to be.
If the clients configured to place say place element of data in = attribute x, it shouldn't try to put it elsewhere. It should fail.
While certainly one could design a client such as it could be configured = with fallbacks for attributes, and fallback for fallbacks, etc., this is = an unnecessarily complication IMO.
Also, note that were a client to attempt the above, it could still fail = due to an element being marked inactive between the time it read the = schema and the time it tried the DIT update. Of course, one could = complicate the client further by trying to handle this as well.
=20
Instead, they should just try the update and, if it fails, report it as they normally would.
=20 Modifying existing data I first have to think about... =20
Handling the inactive condition locally hides the error from the =
directory=20
administrator, who is likely relying on directory server logs to find=20=
applications which using inactive schema.
=20 Hmm, that's not the case with a schema-aware client anyway which =
guides the
user *not* to use OBSOLETE schema elements.
I generally assume the user is not selecting which attribute to store = some piece of information into. I assume the client been programmed to = collect a piece of information and configured (or programmed) where to = store it.
The client you refer to is what I would call an application-neutral LDAP = directory administration tool. For such a tool, it might be reasonable = to warn the user (whose generally an "administrator" of some sort as = opposed to a "normal" user). =20
You're likely talking about detecting pre-configured applications with hard-coded use of OBSOLETE =
object
classes and attribute types. Most times these are not schema-aware at all.
Well, pre-configured applications may be schema-aware but maybe not as = fully as an LDAP directory administration tool might be. They might = check that the element they were configured to use is appropriate for = that use by examining its specification in the subschema.
-- Kurt=