[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: slapd python backend

> On Thu, Dec 09, 1999 at 11:54:24PM +0100, bert hubert wrote:
> > On Thu, Dec 09, 1999 at 05:16:46PM -0500, Andy Dustman wrote:
> >
> > > Since this doesn't seem to exist, I'm writing one. With the
> enthusiastic
> > > consent of my employer (comstar.net), it will be turned over to the
> > > OpenLDAP project. I'm presently modelling it off back-perl.
> I'm fairly new
> > > to LDAP (and the OpenLDAP lists), so let know what I should do with it
> > > when it looks fairly alpha.
> >
> > I was wondering today if a 'coprocess' backend would be a good
> idea. This
> > means that all requests to the backend are sent of as lines of text to a
> > remote program, which would than take care of it. See Advanced
> Programming
> > in the Unix Environment (Stevens) for further examples.
> >
> > There are lots of benefits to this approach. It encourages
> *very* modular
> > design, since nothing can be exchanged except prearange
> instructions. It's
> > also lots faster than the shell backend. It doesn't force you
> to use either
> > perl or python. It is also very easy.
> >
> > Lots of other tricks are possible as well.
> >
> > I have implemented a radius server using this concept and it works very
> > well, performance is great. Apache can also be configured to
> use coprocesses
> > when using mod_rewrite. They also support running multiple
> coprocesses when
> > apache spawns multiple processes.
> The shell backend can do this for you. Don't let it's name fool you, it is
> not limited to shell scripts, but to any executable. It passes the query
> on the command line, so any executable program (C, C++, perl, bash, csh,
> python, tcl, ...) can take the request and respond to it. You can read up
> more on it by looking in the openldap-guide (available via the CVS).

Yes, but the shell backend spawns a new process per request. I like the idea
of a long-lived coprocess that can handle multiple requests. It can also
maintain state about sessions, such as authentication info, which the
current shell backend cannot provide.