Return-Path: Delivered-To: apmail-lucene-java-dev-archive@www.apache.org Received: (qmail 38608 invoked from network); 30 May 2009 10:35:26 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 30 May 2009 10:35:26 -0000 Received: (qmail 94874 invoked by uid 500); 30 May 2009 10:35:37 -0000 Delivered-To: apmail-lucene-java-dev-archive@lucene.apache.org Received: (qmail 94776 invoked by uid 500); 30 May 2009 10:35:37 -0000 Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: java-dev@lucene.apache.org Delivered-To: mailing list java-dev@lucene.apache.org Received: (qmail 94768 invoked by uid 99); 30 May 2009 10:35:37 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 30 May 2009 10:35:37 +0000 X-ASF-Spam-Status: No, hits=3.4 required=10.0 tests=HTML_MESSAGE,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [208.97.132.119] (HELO spunkymail-a10.g.dreamhost.com) (208.97.132.119) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 30 May 2009 10:35:25 +0000 Received: from [192.168.0.102] (adsl-074-229-189-244.sip.rmo.bellsouth.net [74.229.189.244]) by spunkymail-a10.g.dreamhost.com (Postfix) with ESMTP id 3AAD81614EB for ; Sat, 30 May 2009 03:35:03 -0700 (PDT) Message-Id: From: Grant Ingersoll To: java-dev@lucene.apache.org In-Reply-To: <786fde50905292022u61b9f28fpaad4bd8ca87399e3@mail.gmail.com> Content-Type: multipart/alternative; boundary=Apple-Mail-46--915469679 Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: Lucene's default settings & back compatibility Date: Sat, 30 May 2009 06:35:02 -0400 References: <9ac0c6aa0905210925q2df382d2v6d8ea95a8cc69c14@mail.gmail.com> <9ac0c6aa0905221314q6f858920xa284fe11b21407a9@mail.gmail.com> <786fde50905232320n77339870i8a0f806031d2f836@mail.gmail.com> <9ac0c6aa0905240328v7c45bd8aq8afe6a04b5212443@mail.gmail.com> <786fde50905240511t214f8255p10834490bafbd1bc@mail.gmail.com> <9ac0c6aa0905240548x701cd61di65fbb3b95e28cbbf@mail.gmail.com> <786fde50905241222r2fd2bbfcuee998bd7bcd5340d@mail.gmail.com> <9ac0c6aa0905241325qa17475bje47964edbb1c9130@mail.gmail.com> <786fde50905242118s126333b3y27499c242578f4b@mail.gmail.com> <697C8D45-29CA-4C2F-8BF0-3932F41430B4@apache.org> <786fde50905292022u61b9f28fpaad4bd8ca87399e3@mail.gmail.com> X-Mailer: Apple Mail (2.935.3) X-Virus-Checked: Checked by ClamAV on apache.org --Apple-Mail-46--915469679 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit I think the last piece that is needed is to ask on java-user what others think. In order to do that, I think it needs to be boiled down to a couple paragraphs. -Grant On May 29, 2009, at 11:22 PM, Shai Erera wrote: > So ... I've this happen a lot of times (especially in my thesis > work) - someone raises a controversial topic, or one that touches > the nervous of the system, there's a flurry of activity and then it > dies unexpectedly, even though it feels to everyone that there's "an > extra mile" that should be taken in order to bring it to completion. > > And that's what I've seen in this thread. A lot has been said - lots > of comments, ideas, opinions. Lots of ranting and complaining. Then > it died ... Thank you Grant for that last "beep", I hope that was an > intention to resurrect it. > > So I ask - how come that we don't have a decision? Is it because > we're "afraid" to make a decision? (that last sentence is supposed > to "tease" the community, not to pass judgement) > > I'm asking because it seems like everybody pretty much agrees on > most of the suggestions, so why not decide "let's do X, Y and Z" and > change the back-compat page starting from 2.9? If people don't > remember the decisions, I don't mind reiterating them. > > (I also ask because I'd like to take the improvements from > LUCENE-1614 to TermDocs/Positions, PhrasePositions, Spans. All > except PhrasePositions are public interfaces and so it matters if I > need to go through creating abstract classes, with new names, or I > can change those interfaces, asking those that implemented their own > TermDocs to modify the code). > > Shai > > On Wed, May 27, 2009 at 10:36 PM, Grant Ingersoll > wrote: > So, here's a real, concrete example of the need for case by case > back compat. See https://issues.apache.org/jira/browse/LUCENE-1662 > > It's completely stupid that ExtendedFieldCache even exists. It is > a dumb workaround for a made up problem that has nothing to do with > real coders living in the modern age of development where IDE's make > refactoring these types of things very cheap. Namely, the notion > that interfaces must never change lest every 6-9 months some minute > number of users (I'd venture it's less than 1% of users) out there, > who by any account are completely capable of implementing hard core > Lucene internals (like extending FieldCache), yet are seemingly > incapable of reading a CHANGES file with a huge disclaimer in it, > have to recompile (GASP!) their code and put in a dummy > implementation of some new interface method. Yet, here we are with > Yonik fixing very real problems that are a direct result of coding > around back compat. (along with a mistake; it took a long time for > this issue to even be discovered) that very much effect the > usability of Lucene and the day to day experience of a good number > of users. > > In other words, the real fix for L-1662 is for ExtFieldCache to be > folded into FieldCache and for the file to be removed, never to be > heard from again. > > The same can be said for the whole Fieldable issue, but that's a > different day. > > Ranting, > Grant > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org > For additional commands, e-mail: java-dev-help@lucene.apache.org > > -------------------------- Grant Ingersoll http://www.lucidimagination.com/ Search the Lucene ecosystem (Lucene/Solr/Nutch/Mahout/Tika/Droids) using Solr/Lucene: http://www.lucidimagination.com/search --Apple-Mail-46--915469679 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable I think the last piece that is = needed is to ask on java-user what others think.  In order to do = that, I think it needs to be boiled down to a couple = paragraphs.

-Grant

On May 29, = 2009, at 11:22 PM, Shai Erera wrote:

So ... I've this happen a lot of times (especially in my = thesis work) - someone raises a controversial topic, or one that touches = the nervous of the system, there's a flurry of activity and then it dies = unexpectedly, even though it feels to everyone that there's "an extra = mile" that should be taken in order to bring it to completion.
=
And that's what I've seen in this thread. A lot has been said - lots = of comments, ideas, opinions. Lots of ranting and complaining. Then it = died ... Thank you Grant for that last "beep", I hope that was an = intention to resurrect it.

So I ask - how come that we don't = have a decision? Is it because we're "afraid" to make a decision? (that = last sentence is supposed to "tease" the community, not to pass = judgement)

I'm asking because it seems like everybody pretty much = agrees on most of the suggestions, so why not decide "let's do X, Y and = Z" and change the back-compat page starting from 2.9? If people don't = remember the decisions, I don't mind reiterating them.

(I also = ask because I'd like to take the improvements from LUCENE-1614 to = TermDocs/Positions, PhrasePositions, Spans. All except PhrasePositions = are public interfaces and so it matters if I need to go through creating = abstract classes, with new names, or I can change those interfaces, = asking those that implemented their own TermDocs to modify the = code).

Shai

On Wed, May 27, = 2009 at 10:36 PM, Grant Ingersoll <gsingers@apache.org> = wrote:
So, here's a real, concrete example of the need for case by case = back compat.  See https://issues.apache.org/jira/browse/LUCENE-1662
It's completely stupid that ExtendedFieldCache even exists. =   It is a dumb workaround for a made up problem that has nothing to = do with real coders living in the modern age of development where IDE's = make refactoring these types of things very cheap.  Namely, the = notion that interfaces must never change lest every 6-9 months some = minute number of users (I'd venture it's less than 1% of users) out = there, who by any account are completely capable of implementing hard = core Lucene internals (like extending FieldCache), yet are seemingly = incapable of reading a CHANGES file with a huge disclaimer in it, have = to recompile (GASP!) their code and put in a dummy implementation of = some new interface method.  Yet, here we are with Yonik fixing very = real problems that are a direct result of coding around back compat. = (along with a mistake; it took a long time for this issue to even be = discovered) that very much effect the usability of Lucene and the day to = day experience of a good number of users.

In other words, the = real fix for L-1662 is for ExtFieldCache to be folded into FieldCache = and for the file to be removed, never to be heard from again.

= The same can be said for the whole Fieldable issue, but that's a = different day.

Ranting,
= Grant


= ---------------------------------------------------------------------
= To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For = additional commands, e-mail: java-dev-help@lucene.apache.org

=


--------------------------
Grant = Ingersoll

Search the Lucene ecosystem = (Lucene/Solr/Nutch/Mahout/Tika/Droids) using Solr/Lucene:
=

= --Apple-Mail-46--915469679--