[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/