Return-Path: Delivered-To: apmail-jakarta-lucene-dev-archive@www.apache.org Received: (qmail 26204 invoked from network); 16 Aug 2004 21:40:30 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 16 Aug 2004 21:40:30 -0000 Received: (qmail 7844 invoked by uid 500); 16 Aug 2004 21:40:29 -0000 Delivered-To: apmail-jakarta-lucene-dev-archive@jakarta.apache.org Received: (qmail 7696 invoked by uid 500); 16 Aug 2004 21:40:27 -0000 Mailing-List: contact lucene-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Lucene Developers List" Reply-To: "Lucene Developers List" Delivered-To: mailing list lucene-dev@jakarta.apache.org Received: (qmail 7683 invoked by uid 99); 16 Aug 2004 21:40:27 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=FORGED_RCVD_HELO X-Spam-Check-By: apache.org Received: from [217.160.91.29] (HELO p15112568.pureserver.info) (217.160.91.29) by apache.org (qpsmtpd/0.27.1) with ESMTP; Mon, 16 Aug 2004 14:40:25 -0700 Received: from intrafind.de (ppp-82-135-1-83.mnet-online.de [82.135.1.83]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by p15112568.pureserver.info (Postfix) with ESMTP id C649614015A for ; Mon, 16 Aug 2004 23:40:22 +0200 (CEST) Message-ID: <412129BF.4010304@intrafind.de> Date: Mon, 16 Aug 2004 23:40:15 +0200 From: Bernhard Messer User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lucene Developers List Subject: Re: [Jakarta Lucene Wiki] Updated: Lucene2Whiteboard References: <20040811200629.93470.99119@minotaur.apache.org> In-Reply-To: <20040811200629.93470.99119@minotaur.apache.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N Hi Daniel, just looked at your changes you made on the whiteboard. You moved the "callback interface" idea to "Other Changes". I think that such an implementation would raise a change in the current api. Maybe we can make the new code backward compatible, but at least, we have to add additional methods where a callback object can be passed into classes like IndexWriter e.g. The "logger" idea could be a candidate for "Other Changes". The only thing we would have to do is to add a seperate logger class which can be adressed from the internal lucene classes, which wouldn't have any changes within the api. best regards bernhard lucene-cvs@jakarta.apache.org wrote: > Date: 2004-08-11T13:06:28 > Editor: DanielNaber > Wiki: Jakarta Lucene Wiki > Page: Lucene2Whiteboard > URL: http://wiki.apache.org/jakarta-lucene/Lucene2Whiteboard > > TooManyClausesException; move an entry to the other section > >Change Log: > >------------------------------------------------------------------------------ >@@ -26,6 +26,7 @@ > > 9. Add a non-static method isCurrent() to IndexReader and remove static getCurrentVersion() and lastModified methods: [http://www.mail-archive.com/lucene-dev@jakarta.apache.org/msg06143.html] > >+ 10. Implement an option for error handling described on the mailing list: [http://www.mail-archive.com/lucene-dev@jakarta.apache.org/msg04050.html message] - if the TooManyClauses exception is kept, rename it to TooManyClausesException. > > == Other Changes == > >@@ -33,9 +34,7 @@ > > 1. Add support for span queries to query parser? > >- 2. Implement an option for error handling described on the mailing list: [http://www.mail-archive.com/lucene-dev@jakarta.apache.org/msg04050.html message] >- >- 3. Implement a callback interface for processes which can run for several minutes like IndexWriter.optimize(). The idea is to define a simple public interface which can be implemented by developers using lucene. The object implementing the callback, could be passed to methods like optimize() and can inform the caller when one of the steps to process has finished. This would make it much easier in interactive applications to inform the user that the system is working and not frozen. >+ 2. Implement a callback interface for processes which can run for several minutes like IndexWriter.optimize(). The idea is to define a simple public interface which can be implemented by developers using lucene. The object implementing the callback, could be passed to methods like optimize() and can inform the caller when one of the steps to process has finished. This would make it much easier in interactive applications to inform the user that the system is working and not frozen. > > == Schedule == > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org >For additional commands, e-mail: lucene-dev-help@jakarta.apache.org > > > --------------------------------------------------------------------- To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: lucene-dev-help@jakarta.apache.org