It is not a recommended practice to expose Solr to the end-users because it is so easy to bring down the server if the user knows that it is a Solr server. We must devise a good mechanism to filter the kind of commands that can be served .
On Fri, Jul 11, 2008 at 8:14 PM, Erik Hatcher (JIRA) <[EMAIL PROTECTED]> wrote: > > [ > https://issues.apache.org/jira/browse/SOLR-620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12612894#action_12612894 > ] > > Erik Hatcher commented on SOLR-620: > ----------------------------------- > > Sure, contrib is fine. Where it ends up isn't a big deal to me. > > As for how Solr is deployed - having the web tier and Solr be one and the > same (in a read-only configuration of course) is a pretty compelling way to > deploy, I'd think. Why separate Solr and the UI when using load balanced > replicated servers? Of course it depends on the needs of the application, > but keeping a separate web app to regurgitate what Solr returns can be an > unnecessary deployment hassle. > >> Velocity Response Writer >> ------------------------ >> >> Key: SOLR-620 >> URL: https://issues.apache.org/jira/browse/SOLR-620 >> Project: Solr >> Issue Type: New Feature >> Components: search >> Affects Versions: 1.3 >> Reporter: Erik Hatcher >> Assignee: Erik Hatcher >> Priority: Minor >> Attachments: SOLR-620.jars.zip, SOLR-620.patch, SOLR-620.patch >> >> >> Add a Velocity - http://velocity.apache.org - response writer, making it >> possible to generate a decent search UI straight from Solr itself. Designed >> to work standalone or in conjunction with the JSON response writer (or >> SolrJS) for Ajaxy things. > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > > -- --Noble Paul
