Kurt,
following-up on openldap-technical since this is off-topic in ITS#6151.
Kurt Zeilenga wrote:
On Apr 22, 2010, at 2:58 PM, Michael Ströder 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.
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.
This general statement is pretty blurry without speaking about certain use-cases.
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.
Who said that my or any other client is doing anything like this in case of OBSOLETE schema elements? It would certainly be non-sense.
The only thing I'm trying to achieve is to guide the user in the UI not to get frustrated by trial-and-error.
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.
A client always have to implement proper error control even if the UI is guiding the user along the subschema information.
Instead, they should just try the update and, if it fails, report it as they normally would.
Modifying existing data I first have to think about...
Handling the inactive condition locally hides the error from the directory administrator, who is likely relying on directory server logs to find applications which using inactive schema.
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.
With web2ldap it's a mix of both: One can pre-configure HTML templates per object class for input forms with which the web2ldap admin specifies the descriptive labels around an input field. With this you can hide which LDAP attribute the data is stored into. But the user can also switch to table and LDIF input fields (and back to tempating) when editing the data.
In the template and table input forms I'd like to grey out input fields where the user's input would lead to a schema violation (OBSOLETE). E.g. it does not make sense to present OBSOLETE object classes in the object class select form when adding/modifying entries. It's similar to use slapo-allowed to only display editable input fields of attributes a user is allowed to write to.
On the other hand web2ldap always trys to respect what's already present in the entries. The paradigm is to be minimal invasive: Don't change anything while modifying existing entries if the user did not explicitly change 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).
Even such a tool can have customization. The categories are not that sharp... ;-)
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.
Yes, there are things like this in web2ldap too for certain use-cases (e.g. determining whether it works with MS AD while setting password attribute etc.).
But I was especially interested in discussing what's appropriate in case of OBSOLETE schema descriptions.
Ciao, Michael.