Actually, Oscar, I was suggesting more simple changes, i.e. just make your API
consistent with general Elisp API principles.
For example:
-- Instead of ldap-add-internal, just call it ldap-put and make it the advertised
interface. There is no need to provide an interface like ldap-add that
automatically does an open and a close, displays messages, looks for
ldap-default-host, etc. Follow standard convention and make the caller do this.
ben
Oscar Figueiredo wrote:
>>>>> "Hrvoje" == Hrvoje Niksic
<hniksic(a)iskon.hr> writes:
>> Perhaps, but I think that the code to do anything ldap-ish would
>> still look very ldap-ish as opposed to abstract-database-ish.
Hrvoje> I agree with Bill. Abstract interfaces are a nice thing up to a
Hrvoje> point, i.e. as long as they serve to us and not the other way around.
Hrvoje> If LDAP serves a purpose totally different than a flat database, it's
Hrvoje> quite fine to have a different interface for the two.
Just to add my 2 cts, I also like abstraction and uniform interfaces (after all
EUDC is a simple attempt at that) but I agree 200% with Bill and Hrvoje. The
LDAP APIs are still evolving, adhering to them is the simple way to go. Even
if we devised a good interface above the current API now, nothing guarantees we
could easily fit forthcoming evolutions into it. I, for one, won't go that way
but I won't discourage anyone that would like to implement such an interface.
Oscar
------------------------------------------------------------------------
Part 1.2 Type: application/pgp-signature
Encoding: 7bit