Re: Success Story: Perl Backend

[Pierangelo Masarati <ando@sys-net.it>]

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