Thanks all. I'll have a poke around Hue, but depending on how it goes may end up doing as Jack suggests and extending the existing admin UI.
On 21 September 2013 02:50, Shawn Heisey <s...@elyograg.org> wrote: > On 9/19/2013 5:50 AM, Gareth Poulton wrote: > > A customer wants us to move their entire enterprise platform - of which > one > > of the many components is Oracle Endeca - to open source. > > However, customers being the way they are, they don't want to have to > give > > up any of the features they currently use, the most prominent of which > are > > user friendly web-based editors for non-technical people to be able to > edit > > things like: > > - Schema > > - Dimensions (i.e. facets) > > - Dimension groups (not sure what these are) > > - Thesaurus > > - Stopwords > > - Report generation > > - Boosting individual records (i.e. sponsored links) > > - Relevance ranking settings > > - Process pipeline editor for, e.g. adding new languages > > -...all without touching any xml. > > I think Jack and Alexandre have pretty much covered what exists now for > Solr without paying someone for features and support - not much. There > is however some background work underway to bring features exactly like > this to Solr. Except for the Schema REST API that exists right now, I > don't think any of it has much priority. The priority is likely to > increase in the future, but probably not fast enough for your needs. > > There is a strong desire among the top Solr developers to have Solr > always be in SolrCloud mode in a future major version release -- which > means it would use Zookeeper to store all config information, just like > SolrCloud does now. > > When your config is in a separate network service instead of traditional > config files, the ability to edit the config using API calls is very > important. Creating a UI front-end that uses the API and doesn't > require editing XML would be EXTREMELY nice. I'm pretty sure that this > is the goal with the current work on the Schema REST API. > > If you have any idea how to bring these features to Solr, patches are > always welcome! > > Some of the things in your list, particularly facets and grouping (which > is what dimension groups might be equivalent to) are normally handled in > client code. The application creates the parameters it needs and > handles the response. With Solr they aren't normally configured on the > server side. You could do so, by putting parameters in request handler > definitions. > > Thanks, > Shawn > >
