[Date Prev][Date Next]
Re: slapd internal API change
Using a single interface and possible a single function for different
is a good idea indeed... now it became much easier to manage callback
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
IS_PSEARCH does not seem to be required, because we can get the same
from sop->o_clientupdate_type or sop->o_sync_mode.
BTW, removing #ifdefs around LCUP / SYNC code will make the search code
If you're done with the API change infrastructure, then I'll start refining
the psearch-search integration.
thanks again !
Jong Hyuk Choi
IBM Thomas J. Watson Research Center - Enterprise Linux Group
P. O. Box 218, Yorktown Heights, NY 10598
(phone) 914-945-3979 (fax) 914-945-4425 TL: 862-3979
"Howard Chu" <firstname.lastname@example.org>@OpenLDAP.org on 03/30/2003 02:36:05 AM
Sent by: owner-openldap-devel@OpenLDAP.org
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,
most of the definitions are now identical. I think the 4 slap_callback
for example, could be consolidated into 2, or maybe just 1, using the
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
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
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
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
Symas: Premier OpenSource Development and Support