I would have to agree with Peter on this issue. Also, Doug's solution makes a lot of sense to me. If I had the right to vote, that would be the solution I would choose.
***************************** Daniel C. Armbrust Medical Informatics Research Information Services Mayo Clinic Rochester ***************************** -----Original Message----- From: Peter Carlson [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 29, 2002 11:48 PM To: Lucene Developers List Subject: Re: [Bug 12137] New: - Can '*' or '?' symbol be used as the first character of a search? I agree that end users (or app users) will not worry about if a query is expensive, they are just trying to get done what they need to get done. But, I would also say that we should not hinder app developers from providing the functionality their app users need. If a query takes 5 min, but it is the most efficient way to get the information they need, don't you think that this is the app developers choice, since they are supporting the app user. I think it is the responsibility of the app developer, not the Lucene developer, to provide the infrastructure required to meet a given set of requirements. I would agree that it is the Lucene Developer's job to inform the app developer about the tool they are using, but I would also say that since we don't know what problem an app developer is trying to solve, and what resources they have so solve it Lucene developers should try to provide tools to solve it, with the appropriate information about using those tools. If many app developers wants functionality, why wouldn't we offer a configuration to solve their problem? Their response time may meet their requirements. If they have the world as users and must have a quick response time, then the app developers should make the decision to not use a expensive query. This happens all the time with other development environments. For example, the default for Tomcat is to check if a jsp page should be checked and recompiled on the fly if it's changed. This feature is great for development, but slows down a production system. They did however include the feature as a default. Also, you are making an argument that we shouldn't include functionality, but the app developer will implement the functionality (as has been shown) and potentially not know the ramifications of what they have done (also potentially has has been shown). If we provide a configuration for an expensive query and provide details about why it's expensive, then this will put more information in the hands of the app developer to either include it or not in their query syntax. It won't just be an unimplemented feature, but a feature that should be used with caution. The question is not if app developers will implement expensive query features, but if they do how much will they understand what they have developed and understand the limitations of Lucene. --Peter -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
