[Date Prev][Date Next]
Re: (ITS#5312) ldapmodify(1) man page claims that "changetype:" not necessary
> Howard Chu writes:
>>> If anything, the LDIF RFC could be revised instead. This format has
>>> been supported since umich ldap (before the LDIF RFC was written).
>> That doesn't mean it has any relevance today; there's plenty of stuff
>> UMich did that was long since deprecated.
> True, but this was not deprecated that I know of.
It is now. ;) The outcome of the original discussion, which Kurt again
reminded me of today, was that ldapmodify should quit its guessing games and
just accept valid LDIF input. The description of the exceptions in the manpage
seemed imply they were there to accommodate slurpd users, who needed a
mechanism for applying failed updates to a target server. Now that all
slurpd/replog support has been dropped, there really is no more justification
for these exceptions.
> Snipping a bit from the -devel thread:
> Howard Chu wrote:
>> (Did I mention that I've always thought the mod-spec definition was
>> garbage? The format I use for the logschema has none of these problems
>> or inefficiences...)
> As far as I can tell Logschema doesn't support full LDIF modify though.
> reqMod is unordered, so one cannot make two modifications to the same
> attribute. E.g. "delete: foo" followed by "replace: foo".
I suppose reqMod should be made ordered. My point about logschema is that
reqMod's syntax doesn't require separators/terminators or as many redundant
is a far more efficient representation than
The logschema format is also easily grep-able without resorting to grep
windowing and other such hassles.
> Maybe it's time to take this to the ldapext list and hear what others
This is really getting off topic, unless you're suggesting that we spec this
for a new version of LDIF.
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/