Howard Chu writes: > 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.
All I see in the -devel discussion is about bugs in the parser. I see nothing about removing the default "add:"/"replace:" derived from "changetype:", though perhaps it's in the off-list discussion it refers to. > 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. That's not my impression, nor my recollection of the -r option. The manpage lists some differences from ldif format - replog, and defaulting changetype, add/replace. But they do not seem related. Not in the old code either; removing replog code can be done cleanly and does not interfere with those defaults. BTW I was wrong about when -r was removed. Seems to have been in the middle of the 2.0 branch; I only checked the beginning. ldapmodify rev 1.97, May 2 2001 "Clean up some logic, based upon Novell patches". I see a small patch from Novell shortly before that, ITS#1075, about a bug in the -r option. The "patches" referred to means more I've missed, I guess. >> 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 > - Which is why I want the old 'replace:' default back... With a doc warning that one must use the verbose LDIF format if one wants to not worry about attribute names like "increment" or "changetype". > The logschema format is also easily grep-able without resorting to grep > windowing and other such hassles. And that was roughly the old ldapmodify format. See manpage umich ldap-3.3/doc/man/man1/ldapmodify.1. I wonder why we removed it. There are a few weird LDAP change requests that do not map to that format, e.g. add: cn cn: foo - add: cn cn: bar - but that could have been fixed simply by allowing a '-' line as in the current format. >> 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. Not really, more the opposite - if we just relax some restrictions on the old format ldapmodify accepted before, that's fine. But otherwise, if we end up inventing a new way to parse ldifs rather than just accepting more of what the code accepted before, I think it'd be best to see what others do first. And if so we might as well go further. I don't suggest that as part of resolving this ITS, certainly. -- Regards, Hallvard
