Re: commit: ldap/servers/slapd/back-perl SampleLDAP.pm

[Dagobert Michelsen <dam@baltic-online.de>]

Hello,

Am 15.06.2007 um 16:52 schrieb Gavin Henry:
> <quote who="Dagobert Michelsen">
> > I have a reworked Perl backend almost finished. Please don't
> > kick the backend out now, it should be ready in a few weeks.
>
> I'm pretty sure that's not the plan. What sort of things are you  
> doing?

The current Perl backend is practically unusable because of the
following reasons:

- every call goes through a single mutex so the backend is
  essentially singlethreaded
- the backend has no idea of connections so requests can not
  be associated to a specific bind
- binary attributes can not be passed as only zero-terminated strings
  are passed to perl
- argument passing in general is cumbersome as the detailed structure
  is lost via entry2str
- important entry points like 'extended' is not implemented which
  is needed for ldappasswd
- there is no support for multiple databases with Perl backend

The reworked backend works as follows:

- each Perl backend database has a separate Perl interpreter
- each connection gets an interpreter cloned from the specific
  backend. Interpreters are recycled in a pool for performance
- concurrent requests to different interpreters can run
  concurrently in separate threads
- connections are correctly tracked with individual objects
- binary attributed are correctly passed in Perl scalars
- argument passing is done in a style similar to Net::LDAP,
  parsing is no longer needed as attributes and values are
  separately stored
- named arguments make future extensions possible
- additional information about the connection is optionally
  passed as named parameter. It may be advisable later to
  used magic scalars allowing access to all internal
  data without the overhead of processing the arguments
  ahead of time.
- entry points for connection_init, connection_destroy,
  extended ops and unbind are implemented.
- multiple databases are supported.
- unimplemented entrypoints automatically return 'unwilling
  to perform'
- switching to old-backend-compatible-mode is done when
  no connection_init method is found

What is missing:

The new backend is not 100% compatible to the old backend
due to the lack of data sharing. This is a complex issue
but maybe solvable with the help of the mod_perl code.
Alternatively the code could fall back to a single
interpreter when compatibility mode is on. I am trying
to avoid legacy compatibility code in the C part and
move that to a Perl module interposed between back-perl
and the oldstyle module. To make this as easy both for
legacy- and new users is a thing I am still working on.
Personally I dislike the idea of breaking compatibility,
however I don't know how much people actually use the
Perl backend broken as it is. The new API is designed
to be as extendable as possible to avoid incompatible
changes in the future.

The 'abandon' entry point is not implemented. That would
imply signaling between threads I haven't done yet.

I see the use of the Perl backend twofold:

(1) rapid prototyping for functionality later implemented
    in C
(2) implement complex tasks which would be too expensive
    (in terms of time) to do in C

It is still not possible to do all things from Perl which
can be done in C. Exposing more datastructures and functions
to Perl may even make it possible to write overlays in Perl
in some distant future.


Best regards

  -- Dagobert