Re: [21.2] LDAP add and delete functions + interrupt fixes

William> karlheg(a)cathcart.sysc.pdx.edu (Karl M. Hegbloom) writes: Ben> Actually, Oscar, I was suggesting more simple changes, Ben> i.e. just make your API consistent with general Elisp API Ben> principles. Ben> For example: Ben> -- Instead of ldap-add-internal, just call it ldap-put and Ben> make it the advertised Ben> interface. There is no need to provide an interface like Ben> ldap-add that automatically does an open and a close, Ben> displays messages, looks for ldap-default-host, etc. Follow Ben> standard convention and make the caller do this. >> But then just about every program that uses it will need to define a >> wrapper function that does all that. William> The current ldap-add is very inneficient if you are going to be making William> anything other than _1_ modification, which isn't usually the case (at William> least when I use ldap :) Then we should make it better. I do not agree with Ben when he says that there is no need to provide an interface like ldap-add. As Karl stated, most applications will need to perform the same sequence of calls the same host parameters lookup, etc... Such an interface provides (or should provide) what the vast majority of programmers will want to do in a clean, safe and efficient way. Adding a record or performing a search always involves the same sequence of calls, we will avoid duplication and most of all, mistakes by providing good high-level functions. For instance, when using the ldap-*-internal functions, Bill forgot to use ldap-close. If he did, then most programmers will as well. William> I was thrown off by the fact that the LDAP routines you are supposed to use William> if you make the connection your self are all named 'xxx-internal', which William> means (to me) 'DO NOT USE THIS DIRECTLY', etc. Kind of like William> open-network-stream-internal and friends. That was indeed my intention. It's not that the ldap-*-internal should not be used by programmers at all, they're just not the preferred way to do things. Let me restate the rationale of the current API. I've had two goals when designing it. First I wanted the C code to be kept as small as possible, all complex argument processing being moved to the Lisp-level. Then I wanted to provide an API reminding the traditional LDAP command-line tools so that someone who knows LDAP wouldn't be put off by a new API. Therefore the C code is designed to provide the most basic wrappers around the LDAP API calls. The functions in ldap.el provide the preferred programmer interface. If they're not good enough then we should strive to make them better, not simply discard them. Oscar