[
https://issues.apache.org/jira/browse/SOLR-3619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13414612#comment-13414612
]
Mark Miller commented on SOLR-3619:
-----------------------------------
bq. One size does not fit all.
Thats fine - one size can fit a lot though! And the initial size is very
important to people first trying Solr out! This is an important person to the
project! New users. 5 blueprints are fine! They certainly are not necessary in
tons of cases! We should have a great out of the box experience and provide
examples and uses cases up the whazoo on top of that. Your talking about
pleasing one segment of the users - some of the more advanced ones.
I'm talking about pleasing more segments. The advanced guys don't lose out, and
new advanced and noob guys like it more. I don't even believe the direction
your promoting pleases the advanced users. They want it easy too. I've been
listening to a lot of developers - and these days I hear more and more - they
are looking for software that is easy to get started with. Not software that
feels "enterprise". Many of these people are doing things where the search
engine is not the primary system - they want it to just work to the best that
it can. Everyone I know (including me) really disliked FAST and the like. Devs
are not looking for software that looks like it has a high hurdle to get
started. Know why MongoDB is so ridiculously popular right now? It has many
rival techs you can choose instead.
bq. If newbies try to shuffle in some office docs of their own, chances are
they won't have a clue of how to get that done
I don't believe that at all. Good examples and doc and intro tutorials are how
people learn to get started - it's easy to explain how to use the built in
dynamic fields! It's easy to explain you might want to take a moment and add a
couple fields! It's a lie to say you should think of the whole conf dir as an
example and you should not consider using it in production. Why not? People do
it with just some tweaks all the time - I've seen the configs. And we can make
it even better. Jumbo shops will still want to hire consultants to tune things
for harder problems - but Johnny blogger will also be able to get get up and
hopping in 3 seconds. Drupal is a huge user base of Solr. Users that don't want
to pay for hosted Solr should be able to setup and use Solr with ease! Ruby and
Drupal users generally just take all the example config and then just plop a
custom schema.xml in. That's it - and that's fine. That is how easy it should
be. Later, if they find they are scaling and have some issues, they can start
to peak into solrconfig.xml. They should not feel that they better go tackle
right away or else there will be trouble! You should not have to tell the army
of devs that use Solr for minor side projects and the like that OutOfTheBoxSolr
will not work for you. All these guys accessing Solr from wordpress plugins,
from ruby and php and perl, from Drupal - they should be able to run Solr with
ease IMO. And it should end up working for the advanced guys as well. I think
people like to be able to string up systems quickly and easily - and then go
back and tune. Not the other way around. And I think it's silly to try and prod
them into doing the other way around. You really don't have to customize any of
your config until you need to.
> Rename 'example' dir to 'server'
> --------------------------------
>
> Key: SOLR-3619
> URL: https://issues.apache.org/jira/browse/SOLR-3619
> Project: Solr
> Issue Type: Improvement
> Reporter: Mark Miller
> Assignee: Mark Miller
> Fix For: 4.0, 5.0
>
> Attachments: SOLR-3619.patch, server-name-layout.png
>
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
