Re: PATCH: back-sock

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

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