Howard Chu wrote:In those cases race conditions modify the success of the operation, not the resulting state.
"The ordering-prefix may also be used in Modification requests to
specify which values to delete, and in which position values should be added. When processing deletions and insertions, all of the ordinals are recounted after each individual modification."
I think this is unworkable in any situation where multiple clients perform operations - clearly there will be race conditions. The only way to avoid those race conditions in the delete case is to include the value, which makes the ordering element moot. I don't believe there is a reasonable method of avoiding race conditions for inserts in the current scheme. Perhaps adding a control with the values either side of the insert point would help, at least by notifying the time T2 modifier that things have changed.
That's a good point. I only envisioned using this for configuration info that doesn't change frequently and isn't changed by more than one entity. If it turns out that this is just a cute idea that's more trouble than it's worth we can just drop it, since the basic goal of preserving ordering is still generally applicable.
Reconsidering that. This is no worse than multiple clients performing Modify/Replace operations concurrently.
Also, it's essential to be able to specify the ordinal position when inserting new values into a list, or changing an existing value without altering its position.
Right, but the point was it is subject to race conditions.
-- Pete
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext