[Date Prev][Date Next]
Re: Filter string representation (Was: commit: ldap/servers/slapd syncrepl.c)
- To: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
- Subject: Re: Filter string representation (Was: commit: ldap/servers/slapd syncrepl.c)
- From: Howard Chu <email@example.com>
- Date: Tue, 10 Jan 2006 19:53:58 -0800
- Cc: firstname.lastname@example.org, OpenLDAP Devel <openldap-devel@OpenLDAP.org>
- In-reply-to: <email@example.com>
- References: <200512151207.jBFC7ulH052216@cantor.openldap.org> <firstname.lastname@example.org> <email@example.com>
- User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051221 SeaMonkey/1.5a Mnenhy/0.7.3.0
Kurt D. Zeilenga wrote:
At 08:12 AM 12/15/2005, Pierangelo Masarati wrote:
Log Message:On a related note, we keep converting filters from the exploded to the
fix filter generation (back-ldap uses string form)
string form. Most of the backends, and the frontend, only need it in
exploded form; the string form is only used for logging and by the proxy
The string form was originally only constructed for
logging purposes. I would be fine with changes where we
only constructed the string form when logging.
Yes, makes sense. Especially given ITS#3707, where the filterstr is
actually not directly usable. (back-shell uses it directly as well, and
would also have problems).
I've used str2filter() on the filterstr as a way to duplicate an
existing filter; was too lazy to write an actual filter_dup function but
clearly we should have a filter_dup() function instead.
Also regarding ITS#3707 and unknown filter attributes - I want to add a
type/name field to the *Assertion structures, so that incoming filters
with unknown attribute types can be proxied transparently.
What about providing the filter in one form only, generating
the other only if and when required, and destroying both at the end? In
this case, a bdb database with logging off would save a few cycles; on the
converse, internal ops could be only written in string form, which is
developer friendly, and if the op is handled by a proxy there would be
(almost) no need to explode it. I'm not going to change this now, because
savings would likely be very limited, but in case...
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/