Mailing-List: contact lucy-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: lucy-dev@incubator.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <20110418193946.GA14039@rectangular.com>
References: <D3E8E7A4-36DA-431F-847C-D2391FDDB637@kineticode.com>
 <4DA90CA0.6010509@peknet.com> <20110418193946.GA14039@rectangular.com>
From: Nathan Kurz <nate@verse.com>
Date: Sat, 23 Apr 2011 15:44:07 -0700
Message-ID: <BANLkTinyBfm-+8DRFxC4_v-kXZQ9Dp9Ttw@mail.gmail.com>
To: lucy-dev@incubator.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [lucy-dev] Host QueryParser reimplementations

On Mon, Apr 18, 2011 at 12:39 PM, Marvin Humphrey
<marvin@rectangular.com> wrote:
> On Fri, Apr 15, 2011 at 10:27:28PM -0500, Peter Karman wrote:
>> I think the focus on reliable, flexible *Query classes has been a good d=
esign
>> choice to date, because it means that it is quite straightforward to rol=
l your
>> own query parser (as I have done), entirely suited to your application's=
 needs,
>> sidestepping the Lucy QueryParser altogether. That's good library design=
, imo.
>
> Perhaps we can build on that foundation.

I've been disagreeing with a number of things lately, but this one I
strongly agree with:  it's great to have an easy to create and well
defined data structure which serves as the canonical representation of
what a user wishes to search for!  So long as this is clear and easy
to create, it doesn't really matter how extensible the built in parser
is.

> I'm thinking of starting a project at apache-extras.org, with the working
> title "LucyX::Search::HostQueryParser". =C2=A0Its primary purpose would b=
e to
> supply hackable reimplementations of Lucy::Search::QueryParser in the hos=
t
> language, typically using a parser generator -- Parse::RecDescent for Per=
l,
> maybe pyparsing for Python, etc.

Sounds like a good idea.  My only question would be whether "LucyX" is
the right namespace for this.  I've never particularly liked it as a
name, and once we have multiple people contributing it doesn't really
make a difference whether they are stomping on each others "Lucy"
objects or "LucyX" objects.  I wonder whether just "Lucy::Perl::*",
"Lucy::Python::*" might be clearer.  But no strong objection.

--nate