John Dennis wrote:
Rob Crittenden wrote:The XML-RPC interface for updating things is a bit funky. One needs to pass in the original entry and the new one and those are diffed and committed by the API.Don't all the problems and issues go away if the API for modification took add, modify and delete parameters? That seems easier, cleaner, and more efficient. I'm pretty sure most callers will easily know whether they've added, modified, or deleted an attribute. If for some reason they don't have that knowledge we could provide a helper utility to compute it, but I doubt that would be needed in most cases.Kevin liked doing it this way because it decreased the chance of mid-air collisions.So if admin A and admin B both edited user U at the same time but updated different fields both commits would succeed if we send the original record. Otherwise one would stomp on the other.That is fine but not everyone will want to carry the original data around merely to pass it back. I'm proposing a compromise: we provide both.I want to make it support an empty record ('') for old. If that happens then we look up the current record and use that as the "old" entry. Otherwise we use the one passed in. Alternatively I could create a separate set of calls, one that handles old and new and one that just handles new but that might be even more confusing.Opinions?
The reasoning is that it saves a lot of round-trips. Each XML-RPC request requires:
1. An SSL connection 2. A kerberos authentication 3. One or more LDAP connections 3.1 A kerberos auth 3.2 The LDAP operationThis also makes it easier for callers because they don't have to track that stuff. Just change willy nilly in the record they have and the server will handle doing the right thing (or last-update wins in this case).
Description: S/MIME Cryptographic Signature