> 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