[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: (ITS#5662) Comments in schema declarations separated by semicolon



Michael Ströder wrote:
> Howard Chu wrote:
>> As for truncating the comments on input - kind of pointless. In
>> particular, that means those comments won't be persisted in cn=config.
>
> The comments wouldn't have to persist in cn=config.

Perhaps not, but that makes the data in cn=config less comprehensible than it 
would be in slapd.conf. On the other hand, OID macros *are* preserved in 
cn=config, which is yet another reason to use them.

Who benefits from this feature? The comment is there for the benefit of a 
human admin who has to read this definition. If the comment is stripped, then 
the benefit is lost; anyone inspecting the schema remotely will just be faced 
with the unwieldy numeric OIDs.

Remember also, slapd.conf is going to be phased out down the road. It's better 
not to add features to it that people are going to rely on, if the analogous 
feature won't be exposed in cn=config. Instead, we should be making use of 
whatever features already exist that are supported in both.

Hallvard wrote:
> back-config could accept
>   attributeTypes:: base64("description with line endings and comments")
> if it doesn't already.

It still wouldn't persist because e.g. at_unparse() (which provides the value 
that actually gets stored) works by constructing the string out of the LDAP 
Attribute structure. So again, all of the comments would be gone, and there 
would be no embedded line endings.
-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/