[Freeipa-devel] XML-RPC API: update_*

[John Dennis]

Rob Crittenden wrote:
> John Dennis wrote:
>> 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.
>>
>
> 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 operation

I wasn't suggesting separate calls for add, modify and delete. Rather 
one call that takes add, modify and delete parameters. That means it's 
the same round-trip overhead, but without the baggage of having to 
manage before and after attribute dictionaries.

Question: Are we exposing the generateModList API in the python ldap 
module because we concluded it is the optimal and most sensible API for 
us or because it happened to be there and now we're trying to force 
everything to operate that way and in the process introducing 
inefficiency, complexity and special case scenarios?

If one wants to use the generateModList API in the python ldap module 
(not a requirement) then I'm not sure what is being gained by not 
passing the before dictionary other than a marginal reduction in the 
size of the transport during update and a marginal reduction in client 
memory usage to store both dictionaries, one still pays all the 
round-trip costs you enumerate above. The client still has to start with 
a call to query the current dictionary. If you don't have the current 
dictionary I don't see how you would robustly implement the semantics of 
delete. The reasoning goes like this, if the client fails to set any 
attributes in the new dictionary, a likely scenario if he never queried 
the current dictionary and thus does not know what the current 
attributes are, then on the server the missing attribute in the new 
dictionary will be interpreted as a delete operation on that attribute. 
Ouch, that's not what was expected. Thus to be robust one has to have 
both dictionaries, so what's the advantage? Explicitly passing what is 
being added, modified, and deleted gets you out of the whole mess. Note, 
add and modify could be collapsed into one parameter for greater 
simplicity. But delete must be handled separately. Note delete is 
fundamentally different from add/modify because add/modify pairs the 
attribute with a value, but delete specifies only the attribute.

Maybe we should pop up a level and ask if generateModList is the optimal 
API. I'm not convinced it is, it adds a lot of baggage and complexity 
we're now trying to find ways to eliminate.

Also note at least one round trip can be completely eliminated if we 
don't use generateModList, that alone is a significant performance win.

-- 
John Dennis <jdennis at redhat.com>