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

Re: Success Story: Perl Backend




> On a related note, I guess it's time to develop a scripting overlay
> (could be in PERL) that allows rapid prototyping by providing hooks to
> all operations and responses.  In principle, an overlay can be the basis
> for a custom backend if stacked on top of back-null or back-relay (in
> order of nullity :).


yes, you're right. The operations the backend should provide are therefore:
all LDAP standard operations like bind, unbind, compare, ........ as documented in the relative RFCs
+ open, config, close, destroy.
two structures should be made available to the Perl backend: Operation and SlapReply. Operation travels from C to Perl, SlapReply travels from Perl to C.

The overall architecture therefore looks like that:

1) Frontend ( speaking LDAP with the CLient ) Language C
2) Backend Language C
3) Backend Language Perl

What is interesting for me is the boundary between 2 and 3. Perl has an API to use. However Perl has a little bit different view of variables as C has. Perl is not typed, the variable $foo can hold an integer, a string, a double and a boolean. Perl distinguishes between arrays, hashes and scalar values instead. In perl variables are transfered between subroutines accessing a stack. The same method must be used using Perl from C. Perl is object oriented. I am trying to understand how I can transfer with low cost entire structures from C to Perl. My idea is to create in C Perl Objects and transfer these objects in Perl Space. In our case I would like to map the two structures Operation and SlapReply in C space to the Perl objects Operation and SlapReply.
We will have therefore three objects in Perl :

1) Backend
2) Operation
3) SlapReplay

each of this will have methods to access the private data. Armed with this framework you can run your own Perl Backend using the public methods of these objects.

So my question: Does this sound a good solution ?
2nd question: how is the backend initialized ?   I see bi_open, bi_config, bi_close, bi_destroy,
bi_db_init, bi_db_config, ...    and so on. When is called which operation and where are the hooks in the backend code.

so in the meantime I begin work on the C structure to Perl Object mapping. ....

reinhard





"Pierangelo Masarati" <ando@sys-net.it>
Sent by: owner-openldap-devel@OpenLDAP.org

12/01/2005 23:39

To
reinhard.e.voglmaier@gsk.com
cc
openldap-devel@OpenLDAP.org
Subject
Re: Success Story: Perl Backend





reinhard.e.voglmaier@gsk.com wrote:

>
> Yes, that was what I am looking for. It's outdated, ok. But better
> than nothing.
> Two questions:
> in the Umich Documentation is written that all backend calls contain
> as first three parameters: Backend, Connection, Operation. I have seen
> that the OpenLDAP versions contain only the Operation  as parameter.
> Where do the Connection and Backend come from ?
> I have seen that the foo_back_initialize() routine in the init,c file
> get the BackendInfo as parameter and initialises the single calls with
> the corresponding perl backend routines, but the search, add, delete,
> ...   do not.

Simply forget about that doc.  The frontend and backend API of
OpenLDAP's slapd changed so much since 1.X (which was quite similar to
UMich's, its ancestor).  Now the API is as much as possible standardized
on two structures: the Operation, which contains pointers to the
connection it is part of and to the backend that is honoring it (as soon
as it is available), and the SlapReply, i.e. the response (final or
intermediate, doesn't really matter).

>
> Just that I am working on the subject, what about reviving the
> "Writing a slapd backend chapter" ?

I don't  think it's a good idea for many reasons:
1) it's quite complicated (well, it is simple in terms of guidelines,
but complicated in terms of details)
2) it's changing quite often in the details, and, maybe not that fast,
also in the overall architecture.  It is very likely that such a
document would always be out of date.
3) it is very unlikely that people will need to develop so many new
backends to justify it; in fact, while some time ago a custom backend
was the preferred solution to introduce custom code, at the cost of
redesigning everything (e.g. all the operations), now the preferred
method is to add small bits of code to existing backends thru dynamic
modules, significantly overlays (the ones I prefer) or SLAPI, so that
the custom code is as much as possible backend-independent.

On a related note, I guess it's time to develop a scripting overlay
(could be in PERL) that allows rapid prototyping by providing hooks to
all operations and responses.  In principle, an overlay can be the basis
for a custom backend if stacked on top of back-null or back-relay (in
order of nullity :).

p.



   SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497