Re: Errors in diradmin-1.6.0

Dieter Kluenter wrote:

> I'm quite aware of the enheritage problem with structural object
> classes. There are two solutions to this, either design a new subclass
> and include a host attribute, or use the extensibleObject object class
> and apply the host attribute (RFC 2252). I personally quite often make
> use of the class extensibleObject.

IMO, the extensibleObject object class should be used only in temporary situations (e.g. during 
development where the schema writer is not the same person as the application coder). It is 
basically the same as turning schema checking off for those objects which contain it. If it were up 
to me, LDAP servers would not even include functionality to run without schema checking, including 
extensibleObject.

Of course, we could deliver a schema file. First, we'd need to ask IANA for an OID number. It might 
come in handy for more things than just this one problem.

Would others rather see the use of "extensibleObject" or additional schema?


> An other approach would be a complete redesign with no hard coding of
> any attributes, but read available attributes from the subschema
> subentry, (ldapsearch -b "cn=subschema" -s base +) or (ldapsearch -b
> "cn=subschema -s base attributeTypes objectClasses).

I do like the data-driven approach. We might run into this same mess again when Samba4 comes out... 
  This would be a lot of work, though.

--
mike


-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt