Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Received-SPF: pass (athena.apache.org: domain of elecharny@gmail.com
 designates 66.249.82.228 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=MYfc+avmfcPhWVSZXDjueaDBxfRvokPMv1tVhTuy5E2ZaxvrxEh+m4D5jmDq9jbXSahUkKpMh6D0WyS1lVUAvahrMO4dmBYgyrXrx0HmH4xlazSuJ2CdHcrS+BwviA6WmGIEK0O5iqe+9xIOtuKxkUJn62YYzhTu++fUNboHWBs=
Message-ID: <d45b08f00710020911m1632befdn397651cd8042ee8d@mail.gmail.com>
Date: Tue, 2 Oct 2007 18:11:49 +0200
From: "Emmanuel Lecharny" <elecharny@gmail.com>
Reply-To: elecharny@iktek.com
To: "Apache Directory Developers List" <dev@directory.apache.org>
Subject: Re: [Filters] New parser
In-Reply-To: <46FC05DC.1050508@apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <d45b08f00709270259t5d6b279fmbcc0a1e2b6725b23@mail.gmail.com>
	 <46FC05DC.1050508@apache.org>

Hi Stefan

I have looked at your code, and its purpose is different from what we
need inside the server :
* in the server
 - fast parsing
 - stateless parser
 - fail fast
 - generate a ExprNode tree
 - strict filter
* in the client
 - fast parsing
 - contextfull parser
 - auto-corrective parser
 - generate LdapFilter tree
 - relaxed filter

We need also to be more precise in the way we distinguish nodes :
Substring node and present node are different, for instance.

For those reasons, I don't think it's reasonable to merge the two
parsers, and as they are already tailored for their specific usages, I
think we will waste some time during the merge at the expense of
slower performances on the server.

Btw, your parser is very elegant. I like the decoupling between
tokenization and syntaxic oarsing. Classical Aho, Sethi & Ullmann
compiler technic ;)


On 9/27/07, Stefan Seelmann <seelmann@apache.org> wrote:
> Hi Emmanuel,
>
> we also have a filter parser in Studio. It is a hand-written parser and
> it is optimized to parse incomplete filters while typing the filter in
> the GUI to give some attribute completions and error markers. See
> http://issues.apache.org/jira/browse/DIRSTUDIO-47.
>
> Perhaps you want to take a look at it, but be aware: it isn't strict ;-)
> http://svn.apache.org/viewvc/directory/studio/trunk/studio-ldapbrowser-co=
re/src/main/java/org/apache/directory/studio/ldapbrowser/core/model/filter/
>
> Regards,
> Stefan
>
>
> Emmanuel Lecharny schrieb:
> > Hi,
> >
> > due to some serious reentrant problems we have with the current server
> > implementation, I'm rewriting the filter parser.
> >
> > Things are going well, but I have a question about the syntax. RFC
> > 4515 does not allow spaces inside a filter, but the current parser
> > allows them. For instance :
> > ( ou =3D test ) is valid for our antlr parser, when it's not
> > specifically allowed by the grammar.
> >
> > I can relax the grammar easily, but then we may have issues like :
> > ( ou=3D test) should match "test" or only " test" ? or should we use
> > this filter : ( ou =3D \20test ) to match " test" ?
> >
> > I would favor a strict parser otherwise we will have serious problems
> > with such values containing starting or trailing spaces.
> >
> > Keep in mind that the filter parser will only be used when embedding
> > the server. For a remote server, filters are already parsed by the
> > client.
> >
> >
> > wdyt ?
> >
>
>


--=20
Regards,
Cordialement,
Emmanuel L=E9charny
www.iktek.com