Do you have a use case for this? I'm implementing add-if-not-present to ease the implementation of the version number overlay, so I could implement softdel as well.
I think all of these could make sense also protocol-wise (including softadd), but I'm not in the mood right now to start the formalization process, so I'd leave it to a later time.
Yes. I've had to implement this exact feature in application code before (via search + conditional mod). It appears frequently in middleware stuff when you're merging data from multiple upstream account sources and a registry into LDAP. The softdel case appears less often than softadd, but is extremely useful when trying to cleanup mistakes.
More concretely, middleware performing a multi-db reconciliation sweep can use it to assert implied constraints on each object. For example, if some event happens, the entry must now have attr1=val1, and must not have attr2=val2, but might already be in that situation. This allows for more cases of idempotent atomic changes without needing transactions.
A number of overlays will need to watch for this as it is particularly relevant for groups (memberOf, refint, etc).
Sounds good. In principle, applications should be able to perform *most* of the operations by a proper combination of pre/post read, assert, and permissive controls, but in some cases they'll need more than one write operation, thus losing atomicity (until we have transactions, at least :).
Internal/middleware is a different business, that's why I wanted to discuss this first on -devel. I've updated the patch to include "softdel" (SLAP_MOD_SOFTDEL) as well, although I didn't test it yet. I was going to complete the picture with a "del-if-present", but its semantics can be obtained using "softdel" with NULL values.
At this point, I wonder whether it would make sense to support "softadd", "softdel" and "add-if-not-present" protocol-wise, as they allow more granularity than the permissive modify control.
p.