Howard Chu writes: >Brian Candler wrote: >> P.S. Aside: it struck me after originally writing this code that if >> you're going to use openldap in this way, all that it is doing is >> acting as an ASN1 to back-shell protocol converter. In that case, >> your backend script might as well just talk ASN1 instead of >> back-shell. (...) > > Yes, that was my initial reaction to seeing your description. I.e., you > must write your external module to be a relatively complete LDAP server > that speaks LDIF instead of ASN.1.
That's a bit strong, there are a lot of things the slapd front-end does which such an LDIF server would not need to do. TLS, syslog, IPv4/v6, chroot/chown, a lot of details about parsing and error returns, etc. OTOH, to get these features, one could run a rather primitive LDAP server against a Unix domain socket, and then set up slapd as a front-end which talks to it with back-ldap. I wonder how that compares to the "LDIF server" example included in this patch. > It strikes me that this isn't > necessarily the most wonderful thing to do. > > To me the notions of "externally scripted module" and "production use" > are mutually incompatible. You use a scripting backend to prototype an > interaction, and if it needs to perform well in production use you > rewrite it in C. Even when you have some server/module and want to provide LDAP as an access protocol to it, rather than wanting to set up an LDAP server and use that module as its data store? > The reason I find back-perl interesting is because I > can change its code on the fly, with very little up-front effort, which > makes it easy to test ideas rapidly. If I need to write a listener and > various other server infrastructure before being able to do any useful > work, the costs go up and I might as well just write an overlay on top > of back-null. Indeed, with the overlay mechanism I haven't felt the need > to use back-perl in a very very long time. -- Hallvard
