[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Filter string representation (Was: commit: ldap/servers/slapd syncrepl.c)

Kurt D. Zeilenga wrote:
At 08:12 AM 12/15/2005, Pierangelo Masarati wrote:
Log Message:
fix filter generation (back-ldap uses string form)
On a related note, we keep converting filters from the exploded to the
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/