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

[Rob Crittenden]

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

Well, I think perhaps we could support both. One for those that want 
total control and one API for those who want the system to figure it out.

The generateModList function is not exported. There is no way to see 
what has changed in an object other than doing would generateModList 
would do.

There is no round-trip for generating the mod list. That is done within 
the XML-RPC layer (because the python-ldap one was broken IIRC).

Not sure I'll get to this before the end of the year though.

rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20071212/2ee49aa3/attachment.bin>