Re: slapd internal API change

[Jonghyuk Choi <jongchoi@us.ibm.com>]

Using a single interface and possible a single function for different
callbacks
is a good idea indeed... now it became much easier to manage callback
functions.

And, thanks for the psearch-search integration.
One question is about having LCUP and SYNC related fields (o_clientupdate,
o_clientupdate_type, o_clientupdate_interval, o_clientupdate_state, o_sync,
o_sync_mode, o_sync_state) as the members of req_search_s ?
Options include 1) to have a private pointer in each req_????_s or
2) to have a pointer to the LCUP/SYNC data structure in req_search_s.

I'll make the LCUP / SYNC use the same structure member instead of having
them separately.
IS_PSEARCH does not seem to be required, because we can get the same
information
from sop->o_clientupdate_type or sop->o_sync_mode.

BTW, removing #ifdefs around LCUP / SYNC code will make the search code
cleaner.

If you're done with the API change infrastructure, then I'll start refining
the psearch-search integration.
thanks again !

- Jong

------------------------
Jong Hyuk Choi
IBM Thomas J. Watson Research Center - Enterprise Linux Group
P. O. Box 218, Yorktown Heights, NY 10598
email: jongchoi@us.ibm.com
(phone) 914-945-3979    (fax) 914-945-4425   TL: 862-3979


"Howard Chu" <hyc@highlandsun.com>@OpenLDAP.org on 03/30/2003 02:36:05 AM

Sent by:    owner-openldap-devel@OpenLDAP.org


To:    <openldap-devel@OpenLDAP.org>
cc:
Subject:    slapd internal API change



The API change I talked about at the ODD is now committed to CVS HEAD. Both
back-bdb and back-ldbm pass the test suite; I have not tested any of the
other backends. I didn't update:
 back-meta, back-monitor - need to check with Pierangelo
 back-perl - looking at Eric Stokes' patches still
 back-sql - don't have any SQL libraries to build with

This change makes a number of the different function typedef's redundant,
as
most of the definitions are now identical. I think the 4 slap_callback
defs,
for example, could be consolidated into 2, or maybe just 1, using the
sr_type
field to distinguish what needs to be done.

The original idea was to put everything - request parameters and results -
into the Operation structure. This turned out to be a bad idea in the
presence of persistent searches, which keeps the Search Operation hanging
around for later use. So I broke out the result parameters into a separate
SlapReply structure. This allows multiple threads to generate persistent
search responses without any contention issues.

As I was going thru the (back-bdb) persistent search code, I saw that much
of
it was a copy of the original search code, but it was a copy from several
revisions back, missing some bug fixes and such. Rather than try to bring
it
up to date, I munged all of it into the existing search.c. The result is a
large and ugly search function. I'm not sure this was a great idea, as the
readability is poor, but I think it's better than fixing two sets of
similar
code in two different places. It needs some close attention though; I may
have missed something in the merge. (Don't know, haven't tried it.)

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support