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

[Howard Chu <hyc@symas.com>]

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
> > backends.
> >     
>
> 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.
> Kurt
>
>   
> > 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/