Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@lucene.apache.org
Received-SPF: pass (athena.apache.org: domain of jake.mannix@gmail.com
 designates 209.85.211.183 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=WLSo4FrHWaovBH4VUTdMaQU/VAIoNbn7mk2bqhN/5MA1fgt6DuhPblQgXmFfEQlKq+
         I2q5GaEDxsyl+9JYLoQJe4lcVpasn0dgMIsn1CJdhZLy68MoubJvVywJ9ibHFMt9lJQ5
         FeqEJ7mCZZGKeaEo+cJ1eGXDGNhHjBQ7u255s=
MIME-Version: 1.0
In-Reply-To: <4AE1302D.6040707@lucidimagination.com>
References: <8837fb770910142012w5f11ba57y99aeb18493603813@mail.gmail.com>
	 <9ac0c6aa0910220238l5cdce87g314ea18cd85bd695@mail.gmail.com>
	 <8837fb770910221837p287db022i6ed18349977381c6@mail.gmail.com>
	 <4AE114FA.7050309@gmail.com>
	 <8837fb770910221935t6e744eedi2cc129f5df17d508@mail.gmail.com>
	 <c68e39170910222006pcf28e99w4f88c86ceeae2e4d@mail.gmail.com>
	 <4b124c310910222011x10d03a7v608a170340880c75@mail.gmail.com>
	 <c68e39170910222030o162366bcwfbcdc2597199f21d@mail.gmail.com>
	 <4b124c310910222053x71b43f7cue60f33d4bb4ca0ad@mail.gmail.com>
	 <4AE1302D.6040707@lucidimagination.com>
Date: Thu, 22 Oct 2009 21:37:39 -0700
Message-ID: <4b124c310910222137ie0ce222k6187968f31ea20c9@mail.gmail.com>
Subject: Re: lucene 2.9 sorting algorithm
From: Jake Mannix <jake.mannix@gmail.com>
To: java-dev@lucene.apache.org
Content-Type: multipart/alternative; boundary=0016364ed88aa07c26047692c599

--0016364ed88aa07c26047692c599
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Oct 22, 2009 at 9:25 PM, Mark Miller <markrmiller@gmail.com> wrote:

> >> he new API is much harder for the
> >> average user to use, and even for the experienced user, it's not
> terribly fun,
> >> and more importantly:
>
> Do we have enough info to support that though? All the cases I have seen
> on the list, people have figured it out pretty easily - havn't really
> seen any complaints in that regard (not counting you and John - that is
> two). The only other complaints I have noticed are those that happened
> to count on unsupported behavior (eg people counting on no MultiSearcher
> use)
>

John and I and TomS all found it both complex, and we're all pretty serious
users of inner lucene apis.

You see *core developers* saying the api seems fine.  Have you seen *any
users*
of the new sorting api say anything positive about it?  Do you know of
*anyone* who
has implemented the new comparator interface at all,  let alone *likes* it?

3 negative votes by users, in comparison to *zero* positive votes by users
together with a bunch of core developers saying, "yeah it looks easy, what
are
you guys complaining about?".

Internal apis take a while to percolate out to the user base - we're only
the first
few running into this, and while the sample size is small, it shouldn't be
discounted.

Yes, of course it is possible to migrate to the new APIs - which is what we,
as well
as many others, were in the process of doing.  This is just an example of an
API
which got more complex in going to 2.9, and unlike the Collector API, it's
possible
that in this case it wasn't necessary for it to be as complex as it did.

  -jake

--0016364ed88aa07c26047692c599
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Thu, Oct 22, 2009 at 9:25 PM, Mark Mi=
ller <span dir=3D"ltr">&lt;<a href=3D"mailto:markrmiller@gmail.com">markrmi=
ller@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" s=
tyle=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8e=
x; padding-left: 1ex;">
<div class=3D"im">&gt;&gt; he new API is much harder for the<br>
&gt;&gt; average user to use, and even for the experienced user, it&#39;s n=
ot<br>
terribly fun,<br>
&gt;&gt; and more importantly:<br>
<br>
</div>Do we have enough info to support that though? All the cases I have s=
een<br>
on the list, people have figured it out pretty easily - havn&#39;t really<b=
r>
seen any complaints in that regard (not counting you and John - that is<br>
two). The only other complaints I have noticed are those that happened<br>
to count on unsupported behavior (eg people counting on no MultiSearcher<br=
>
use)<br></blockquote><div><br>John and I and TomS all found it both complex=
, and we&#39;re all pretty serious<br>users of inner lucene apis.<br><br>Yo=
u see *core developers* saying the api seems fine.=A0 Have you seen *any us=
ers*<br>
of the new sorting api say anything positive about it?=A0 Do you know of *a=
nyone* who <br>has implemented the new comparator interface at all,=A0 let =
alone *likes* it?=A0 <br>3 negative votes by users, in comparison to *zero*=
 positive votes by users <br>
together with a bunch of core developers saying, &quot;yeah it looks easy, =
what are <br>you guys complaining about?&quot;.<br><br>Internal apis take a=
 while to percolate out to the user base - we&#39;re only the first <br>
few running into this, and while the sample size is small, it shouldn&#39;t=
 be discounted.<br><br>Yes, of course it is possible to migrate to the new =
APIs - which is what we, as well<br>as many others, were in the process of =
doing.=A0 This is just an example of an API <br>
which got more complex in going to 2.9, and unlike the Collector API, it=
9;s possible <br>that in this case it wasn&#39;t necessary for it to be as =
complex as it did.<br><br>=A0 -jake<br></div><br></div>

--0016364ed88aa07c26047692c599--