Re: ldap-haskell questions
Quoth Ferenc Wagner
"Donn Cave"
Now that I look at what I did with ldap_set_option, I recall that s actually a little difficult to assign a type, since the third parameter is sometimes Int, Enum, TimeVal, String, and LDAP_OPT_* values overlap in a way that doesn't really say "enum" to me. So it's reasonably easy to do something, but harder to do it in a way that's generally useful.
I'm also unsure of the portability of the things I'd propose to add. I know only the OpenLDAP API, but something about LDAP_OPT_X_TLS hints that it may be non-standard.
I ended up binding ldap_initialize, which supports ldaps: URL-s, and was achievable in a 10 line absolutely nonintrusive patch (darcs sent). Good enough for me ATM. -- Best wishes, Feri.
On Wed, 26 Jul 2006, Ferenc Wagner wrote: ...
I ended up binding ldap_initialize, which supports ldaps: URL-s, and was achievable in a 10 line absolutely nonintrusive patch (darcs sent). Good enough for me ATM.
Yes, actually that's not just a good solution to your problem but a good idea anyway, since ldap_init() has been deprecated in recent OpenLDAP releases - I believe I had to define -DLDAP_DEPRECATED=1 to build ldap-haskell. I have made a little progress on the work I intended to do, and as of last night I have ldap_start_tls_s working. We need that to use SSL (or rather TLS) with servers that don't bind to a separate SSL port. To raise a perhaps philosophical point, how do Haskell programmers feel about adopted names? In the above paragraph, I said I had "ldap_start_tls_s" working, but my test code calls ldapStartTls, because that's what ldap-haskell's author has been doing. Or would he have written ldapStartTlsS? but Tls looks really weird to me, one would think it should be TLS ... It seems to me that this widespread practice of camel-casing every adopted name comes at some cost and no benefit. With code like ldap_bind_s a b c LDAP_AUTH_SIMPLE names are exactly what you find in the underlying C API documentation, the C include files, etc., and every step away from that costs you some of that transparency. Is it LDAPAuthSimple, or LdapAuthSimple? Is it going to be ldapBindS, or ldapBind? In case it isn't clear, I would like to advocate for a very conservative approach to FFI, with the very minimum changes to names and function to make the FFI work correctly in Haskell terms. That means changing error handling and memory management semantics, but it does not mean apparently gratuitous changes to names, or fiddling with things just because one doesn't fancy them. For example, it really annoys me that though I know execve(2) well enough, I don't have access to this POSIX function in System.Posix.Process but rather have only some wrapper that has helpfully excluded some of its functionality. This didn't need to have been a hard problem - I'm asking for the easy thing! You don't need to know why execve() needs to support argv[0..n]. You don't need to know why there's an ldap_bind_s, and an ldap_bind. Just give me access to the functions the way they are, please! Thanks! Donn Cave, donn@drizzle.com
participants (2)
-
Donn Cave -
Ferenc Wagner