h.b.furuseth@usit.uio.no wrote:
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 attribute references.
attr:- foo attr:+ bar
is a far more efficient representation than
delete: attr attr: foo - add: attr attr: bar -
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 do.
This is really getting off topic, unless you're suggesting that we spec this for a new version of LDIF.