Re: Root DSE

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 09:58 AM 4/20/99 +0200, Julio Sánchez Fernández wrote:
>
>
>"Kurt D. Zeilenga" wrote:
>> 
>> At 06:37 PM 4/19/99 +0200, Julio Sánchez Fernández wrote:
>> >Am I right in thinking that the schema requires an overhaul of
>> >the config file?
>> 
>> Our schema parser (current U-Mich style specification) definitely
>> needs to be updated.  We could extend the parser (ala NetscapeDS)
>> to support v3ism... implement an ASN.1 schema parser... or
>> use an LDIF format input.
>
>There is not much difference between both options because I think
>the biggie is parsing the string representation of the descriptions
>anyway.  I had thought of something like this:
>
>[snipped examples showing old directives with LDAPv3 format values]

This is a step in the right direction.  That is, using LDAPv3
schema format values for attribute and objectclass.  A set of
parse routines can than be implemented (in -lldap or -lldif)
that could be used by both clients and servers!

	ldap_str2objectclasses(value, &oc);
	ldap_str2attributetypes(value, &at);

Structures for objectclasses and attributetypes, of course, would
be needed.  Inverse routines would also be useful.

>Essentially the standard syntax, but allowing newlines for readability.

This could be handled by the config parser.  That is, the config
parser would key on '(', read all lines up to the closing ')' and
then build a string value suitable for calling the above parse
routines.

>The parser would accept both old definitions and new definitions, that can
>be told apart by the presence of the enclosing parentheses.

Backwards compatibility is always nice.

>typedef struct AttributeType {

Separate 'common' fields from SLAPD fields 

That is:
 typedef struct ldap_attributetype {
	char *at_name;
	char *at_desc;
	char *at sup_oid;
	char *at_equality_oid;
	char *at_ordering_oid;
	char *at_substr_oid;
	char *at_syntax_oid;
	int  *at_single-value; /* 0=no, 1=yes */
 } LDAP_ATTRIBUTE_TYPE;

Then in slapd, define:
  typedef struct slap_attribute_type {
	/* v3 attribute type (from config file, for cn=schema) */
	LDAP_ATTRIBUTE_TYPE	sat_attribute_type;

	/* slapd internals */
	struct slap_attribute_type*		sat_sup;
	struct slap_attribute_type**	sat_subtypes;
	...
  }

Likewise for objectclasses and other schema items.

>Syntaxes are hard-wired and cannot be extended.  I think MatchingRule's
>are hardwired too.  Unsure about MatchingRuleUse, it might be useful
>to be able to extend them to cover new AttributeTypes.

In the future, these will NOT be hardwired... but will likely
be only statically extensible.  That is, slapd could be extended
at startup with modules (which would be dynamically loaded) but
would not allow on-the-fly extensibility.

>There is no way with the standard syntax to have 'fax' stand as an
>alias for 'facsimileTelephoneNumber' and the like.

I'm not sure how best to handle aliases.  However, no matter how
we handle aliases, it should be formalized.  That is, we should
document (via an informational rfc) our aliasing handling.  We
should investigate mechnanims for publishing this schema
information.

>> I've been thinking that using LDIF for schema might work out
>> nicely.  In fact, I'm thinking we can (ab)use LDIF for most
>> everywhere we need to exchange information!

Why LDIF?  Using LDIF to specify configuration information lends
itself to placing configuration information in the directory which
lends itself to dynamic modification...

However, this is not as simple as it sounds.  Though feasible,
it's not (IMHO) a high priority item.  But, I think it's a
admirable goal.

I'm am very pleased to see you implementing LDAPv3 style
schema specification.  This is a step in the right direction!

>By the way, I think we should move some of the schema parsing into
>a common library that can be used by slapd, slurpd, ldif2ldbm,
>ldbmcat, etc. (see openldap-bugs for a problem report with slurpd
>not processing include's).

Yes, let's use common (if not standard) formats, common parsers,
and common utilities.

I believe there is a fair amount of duplication betweeen tools,
backends, servers, and clients.  I would like to see these tools
moved to appropriate places for sharing.  Each move should be
independently reviewed.

>> Anyways, I see two urgent project that need volunteers:
>>         * LDIF2 parser
>>         * schema handling
>
>Yeah, any takers? :-)
>
>I have started translating schemas into the syntax I mentioned
>above, checking at every step differences between what we had
>and what we are supposed to have and trying to find the lineage
>of every AttributeType and ObjectClass, their oids, etc..

Great!  I suggest separating parsing of LDAPv3 schema
information for it's use in slapd as suggested above.

>At the very least, this will be useful anyway, translation into
>LDIF would be trivial.

I concur.  Your changes are in the right direction!  Press on!

Kurt