You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-dev@lucene.apache.org by Noble Paul നോബിള്‍ नोब्ळ् <no...@gmail.com> on 2008/07/03 09:14:31 UTC

lesser noise in solrconfig.xml

All the components initialized by Solr have an init(NamedList args)
initializer. This leads us to writing the configuration needed for the
component in the NamedList format. People familiar with Solr may know
the format but most of what is wrtten is noise than information. For
users who are not familiar w/ the format find it too difficult to
understand why they have to write it this way

For example the spellcheckcoponent have a configuration as follows
<searchComponent name="spellcheck" class="solr.SpellCheckComponent">
      <lst name="spellchecker">
         <str name="name">default</str>
         <str name="classname">org.apache.solr.spelling.IndexBasedSpellChecker</str>
         <str name="field">spell</str>
         <str name="spellcheckIndexDir">./spellchecker</str>
    </lst>
</searchComponent>

The most intuitive format for the above configuration would be

as follows
<searchComponent name="spellcheck" class="solr.SpellCheckComponent">
      <spellchecker>
        <name>default</name>
        <classname>org.apache.solr.spelling.IndexBasedSpellChecker</classname>
        <field>spell</field>
        <spellcheckIndexDir>./spellchecker</spellcheckIndexDir>
    </spellchecker>
</searchComponent>

This enhancement can be done automatically by modifying the DOMUtil
class to read the second format to create the namedlist . The new
rules for constructing the namedlist can be.
 * if a tag contains subtags it will be treated <lst>
 * The tag name will be considered as the 'name'
 * All the attributes values will be treated as string.

This can be further enhanced w/ the following rule
* A tag contains attributes will also be a <lst>
* Each attribute will be a String value
The following can be made equivalent to
<searchComponent name="spellcheck" class="solr.SpellCheckComponent">
 <spellchecker name="default"

classname="org.apache.solr.spelling.IndexBasedSpellChecker"
                      field="spell"
                      spellcheckIndexDir="./spellchecker"/>
</searchComponent>

The only problem I see w/ this change is that any plugin that relies
on the type to be something other than string may fail. But that
should not be an excuse for all the new components paying the
"NamedList tax"
--Noble







-- 
--Noble Paul

Re: lesser noise in solrconfig.xml

Posted by Noble Paul നോബിള്‍ नोब्ळ् <no...@gmail.com>.
On Wed, Jul 16, 2008 at 2:43 AM, Chris Hostetter
<ho...@fucit.org> wrote:
> : If the current handlers remain as is (no change in config), What is
> : the best way to enable handlers (especially new ones) to read
> : arbitrary xml configuration?. The only possible solution is to use
> : XPath which I see as very cumbersome.
>
> the init params for request handlers were never ment to be the end all be
> all of configuration -- request handlers with non trivial configuration
> needs can always load any config file format they want from any file they
> want using SolrResourceLoader.openConfig.
If the format is trivial also we must resort to XPath.If the user has
to maintain separate congig files for  extra configuration it is not a
good. Loading the new configuration must also be using XPath or other
xml parsing techniques.

Anyway I have changed the scope of the JIRA issue (no more changes to
csolrconfig). So we do not have to make any changes to the system as
it exists now. Just that we may enable users write components the way
they want
>
>
>
> -Hoss
>
>



-- 
--Noble Paul

Re: lesser noise in solrconfig.xml

Posted by Noble Paul നോബിള്‍ नोब्ळ् <no...@gmail.com>.
Actually even if we do not change the configuration now, if the patch
is checked in new handlers can make use of this (or whoever wants to
use it).
--Noble

On Tue, Jul 15, 2008 at 5:12 PM, Shalin Shekhar Mangar
<sh...@gmail.com> wrote:
> I don't think there is any issue with support if we switch to the new syntax
> only for the features introduced after 1.2
>
> Personally I really like the cleanliness of the new syntax.
>
> On Tue, Jul 15, 2008 at 9:11 AM, Ryan McKinley <ry...@gmail.com> wrote:
>
>>
>>>
>>>> I'm raising my objection to -1 for the updated syntax.  Let's make that a
>>>> post 1.3 (2.0, is my suggestion) feature.
>>>>
>>> Users tend to stick to a released version for very long. A lot of
>>> users (we too) still use Solr 1.2. That means we are going to see this
>>> syntax for atleast another year after which we will ask the users to
>>> switch to a new syntax which they have been using for the past 2+
>>> years.
>>>
>>>>
>>>>
>> I don't like <lst name="nodename"> either, but I don't think <nodename>
>> fixes it.  Especially with the backwards compatibility issues
>> (complications).
>>
>> In 2.0 we should have a more considered syntax -- hopefully something
>> someone could buy a book (if necessary) to understand (spring)
>>
>> so I'm -1 on changing the syntax for 1.3
>>
>> ryan
>>
>
>
>
> --
> Regards,
> Shalin Shekhar Mangar.
>



-- 
--Noble Paul

Re: lesser noise in solrconfig.xml

Posted by Chris Hostetter <ho...@fucit.org>.
: If the current handlers remain as is (no change in config), What is
: the best way to enable handlers (especially new ones) to read
: arbitrary xml configuration?. The only possible solution is to use
: XPath which I see as very cumbersome.

the init params for request handlers were never ment to be the end all be 
all of configuration -- request handlers with non trivial configuration 
needs can always load any config file format they want from any file they 
want using SolrResourceLoader.openConfig.



-Hoss


Re: lesser noise in solrconfig.xml

Posted by Noble Paul നോബിള്‍ नोब्ळ् <no...@gmail.com>.
If the current handlers remain as is (no change in config), What is
the best way to enable handlers (especially new ones) to read
arbitrary xml configuration?. The only possible solution is to use
XPath which I see as very cumbersome.


On Tue, Jul 15, 2008 at 9:11 AM, Ryan McKinley <ry...@gmail.com> wrote:
>>
>>>
>>> I'm raising my objection to -1 for the updated syntax.  Let's make that a
>>> post 1.3 (2.0, is my suggestion) feature.
>>
>> Users tend to stick to a released version for very long. A lot of
>> users (we too) still use Solr 1.2. That means we are going to see this
>> syntax for atleast another year after which we will ask the users to
>> switch to a new syntax which they have been using for the past 2+
>> years.
>>>
>
> I don't like <lst name="nodename"> either, but I don't think <nodename>
> fixes it.  Especially with the backwards compatibility issues
> (complications).
>
> In 2.0 we should have a more considered syntax -- hopefully something
> someone could buy a book (if necessary) to understand (spring)
>
> so I'm -1 on changing the syntax for 1.3
>
> ryan
>



-- 
--Noble Paul

Re: lesser noise in solrconfig.xml

Posted by Shalin Shekhar Mangar <sh...@gmail.com>.
I don't think there is any issue with support if we switch to the new syntax
only for the features introduced after 1.2

Personally I really like the cleanliness of the new syntax.

On Tue, Jul 15, 2008 at 9:11 AM, Ryan McKinley <ry...@gmail.com> wrote:

>
>>
>>> I'm raising my objection to -1 for the updated syntax.  Let's make that a
>>> post 1.3 (2.0, is my suggestion) feature.
>>>
>> Users tend to stick to a released version for very long. A lot of
>> users (we too) still use Solr 1.2. That means we are going to see this
>> syntax for atleast another year after which we will ask the users to
>> switch to a new syntax which they have been using for the past 2+
>> years.
>>
>>>
>>>
> I don't like <lst name="nodename"> either, but I don't think <nodename>
> fixes it.  Especially with the backwards compatibility issues
> (complications).
>
> In 2.0 we should have a more considered syntax -- hopefully something
> someone could buy a book (if necessary) to understand (spring)
>
> so I'm -1 on changing the syntax for 1.3
>
> ryan
>



-- 
Regards,
Shalin Shekhar Mangar.

Re: lesser noise in solrconfig.xml

Posted by Ryan McKinley <ry...@gmail.com>.
>
>>
>> I'm raising my objection to -1 for the updated syntax.  Let's make  
>> that a
>> post 1.3 (2.0, is my suggestion) feature.
> Users tend to stick to a released version for very long. A lot of
> users (we too) still use Solr 1.2. That means we are going to see this
> syntax for atleast another year after which we will ask the users to
> switch to a new syntax which they have been using for the past 2+
> years.
>>

I don't like <lst name="nodename"> either, but I don't think  
<nodename> fixes it.  Especially with the backwards compatibility  
issues (complications).

In 2.0 we should have a more considered syntax -- hopefully something  
someone could buy a book (if necessary) to understand (spring)

so I'm -1 on changing the syntax for 1.3

ryan

Re: lesser noise in solrconfig.xml

Posted by Noble Paul നോബിള്‍ नोब्ळ् <no...@gmail.com>.
On Tue, Jul 15, 2008 at 12:12 AM, Erik Hatcher
<er...@ehatchersolutions.com> wrote:
>
> On Jul 14, 2008, at 12:25 PM, Noble Paul നോബിള്‍ नोब्ळ् wrote:
>>
>> We can choose one clean syntax and stick to it .
>
> -1 to that.... at least in a backwards compatible support kinda way.
backward compatiblity is very important that is why we need to support
the old format. We can probably deprecate the old format in the next
release
>
>> My preference is to have
>> <nodename>
>> <var1>value-1</var1>
>> <var2>value-2</var2>
>> </nodename>
>> because this is the most common way I have seen configuration files
>> instead of.
>> <lst name="nodename">
>> <str name="var1">value-1</var1>
>> <str name="var2">value-2</var2>
>> </lst>
>
> I'm totally with you on that.  I'm mainly speaking from a support sanity
> perspective in my objections to the enhancement.
>
>> I guess we must be able to stick to one snytax irrespective of the
>> underlying framework we use because configurations are harder to
>> change after they have been in use for long.
>
> We could write a converter to go from 1.3 to 2.0, so it certainly isn't a
> showstopper to change syntax.
>
> Also keep in mind that folks surely have (*raising my hand*) written tools
> to generate/modify the config files in their current form.
I have rarely seen a project changing its config syntax in a backward
incompatible way. It is a support nightmare to provide a tool to
migrate cleanly .If we don't even change an API in an incompatible way
forget about the config. Imagine that users have their own custom
handlers also which the tool may not be able to handle .Though , not a
very clean solution , the most practical thing to do is to support the
older version for atleast for one release and phase out the old format
later. It is like marking an API as @deprecated and later on removing
it
>
>> I personally believe that a framework should not define the
>> configuration format instead it should enable us to decide on the
>> format. A lot  of our users are not java users (let alone spring) .
>> They would prefer to have one conventional format (we are already
>> using it in many places in solrconfig.xml as in mainIndex etc).
>
> Not argument there.  Solr needs to move *out* of the configuration business
> though, not making it more complicated with multiple syntaxes.
I still say let us *NOT* have multiple syntaxes. But for backward
comapatibility sake let us support the old one through 1.3. . The
configuration business is not as really ugly . But the syntax  is
>
> I'm raising my objection to -1 for the updated syntax.  Let's make that a
> post 1.3 (2.0, is my suggestion) feature.
Users tend to stick to a released version for very long. A lot of
users (we too) still use Solr 1.2. That means we are going to see this
syntax for atleast another year after which we will ask the users to
switch to a new syntax which they have been using for the past 2+
years.
>
> Let's keep it as-is for now (again, despite my desire for a nicer format, so
> kudos to you for implementing an improvement).
I am not supporting any particular implementation here , But just the
syntax. We can modify the patch or make any suitable changes .
>
>        Erik
>
>
>>
>>
>>
>>
>>
>> On Mon, Jul 14, 2008 at 9:22 PM, Erik Hatcher
>> <er...@ehatchersolutions.com> wrote:
>>>
>>> Personally I'm -0 on this one.   Adding another syntax will possibly
>>> confuse
>>> users and us doing mailing list support when presented with bits of the
>>> config files.   More than one way to do something doesn't seem worthwhile
>>> here.
>>>
>>> While in general I appreciate cleaning up any kind of XML config file
>>> syntax
>>> (by eradicating them altogether ;), I don't think we need to put this in
>>> Solr right now given we want Solr 2.0 to be Springified (can you even
>>> imagine how hideous the config will look then?!)
>>>
>>> I'm even close to saying -1 on this, but I don't want to throw that much
>>> weight behind vetoing it - I really do like a cleaner syntax.
>>>
>>>      Erik
>>>
>>> On Jul 14, 2008, at 11:44 AM, Shalin Shekhar Mangar wrote:
>>>
>>>> +1 for committing it.
>>>>
>>>> Spring may be a pretty big undertaking for which we are not ready at
>>>> this point in time. This patch should be incorporated in 1.3 so that
>>>> at least the new features can take advantage of the simpler style. I'd
>>>> even go as far as to suggest giving a uniform look to the entire
>>>> solrconfig.xml if possible.
>>>>
>>>> On Sat, Jul 12, 2008 at 10:03 PM, Yonik Seeley <yo...@apache.org> wrote:
>>>>>
>>>>> I could go either way on this....
>>>>> I agree with Grant that the "right" way to do things is to use
>>>>> Spring... but that is in the future.  Noble already has the code, so
>>>>> the issue is to commit now or not.
>>>>> I don't care much about getting an XSD for solrconfig myself, but
>>>>> others
>>>>> may...
>>>>>
>>>>> Anyone else have thoughts on this?
>>>>> -Yonik
>>>>>
>>>>> On Fri, Jul 4, 2008 at 11:54 AM, Chris Hostetter
>>>>> <ho...@fucit.org> wrote:
>>>>>>
>>>>>> : It is very hard to validate a config purely using an XSD. We have to
>>>>>> : rely on the
>>>>>> : components themselves to do a validation and I guess it is fine.
>>>>>>
>>>>>> agreed .. but it would be nice if (someday) you can at least check
>>>>>> that
>>>>>> a
>>>>>> config is syntactically correct without running Solr ... an XSD can
>>>>>> help
>>>>>> with that.
>>>>>>
>>>>>> : user every day. According to me the user experience is the most
>>>>>> : important thing. I don't really
>>>>>> : care how many extra lines of code I write to achieve that
>>>>>>
>>>>>> I agree ... i'm just pointing out trade off.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> -Hoss
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Regards,
>>>> Shalin Shekhar Mangar.
>>>
>>>
>>
>>
>>
>> --
>> --Noble Paul
>
>



-- 
--Noble Paul

Re: lesser noise in solrconfig.xml

Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On Jul 14, 2008, at 12:25 PM, Noble Paul നോബിള്‍  
नोब्ळ् wrote:
> We can choose one clean syntax and stick to it .

-1 to that.... at least in a backwards compatible support kinda way.

> My preference is to have
> <nodename>
> <var1>value-1</var1>
> <var2>value-2</var2>
> </nodename>
> because this is the most common way I have seen configuration files
> instead of.
> <lst name="nodename">
> <str name="var1">value-1</var1>
> <str name="var2">value-2</var2>
> </lst>

I'm totally with you on that.  I'm mainly speaking from a support  
sanity perspective in my objections to the enhancement.

> I guess we must be able to stick to one snytax irrespective of the
> underlying framework we use because configurations are harder to
> change after they have been in use for long.

We could write a converter to go from 1.3 to 2.0, so it certainly  
isn't a showstopper to change syntax.

Also keep in mind that folks surely have (*raising my hand*) written  
tools to generate/modify the config files in their current form.

> I personally believe that a framework should not define the
> configuration format instead it should enable us to decide on the
> format. A lot  of our users are not java users (let alone spring) .
> They would prefer to have one conventional format (we are already
> using it in many places in solrconfig.xml as in mainIndex etc).

Not argument there.  Solr needs to move *out* of the configuration  
business though, not making it more complicated with multiple syntaxes.

I'm raising my objection to -1 for the updated syntax.  Let's make  
that a post 1.3 (2.0, is my suggestion) feature.

Let's keep it as-is for now (again, despite my desire for a nicer  
format, so kudos to you for implementing an improvement).

	Erik


>
>
>
>
>
> On Mon, Jul 14, 2008 at 9:22 PM, Erik Hatcher
> <er...@ehatchersolutions.com> wrote:
>> Personally I'm -0 on this one.   Adding another syntax will  
>> possibly confuse
>> users and us doing mailing list support when presented with bits of  
>> the
>> config files.   More than one way to do something doesn't seem  
>> worthwhile
>> here.
>>
>> While in general I appreciate cleaning up any kind of XML config  
>> file syntax
>> (by eradicating them altogether ;), I don't think we need to put  
>> this in
>> Solr right now given we want Solr 2.0 to be Springified (can you even
>> imagine how hideous the config will look then?!)
>>
>> I'm even close to saying -1 on this, but I don't want to throw that  
>> much
>> weight behind vetoing it - I really do like a cleaner syntax.
>>
>>       Erik
>>
>> On Jul 14, 2008, at 11:44 AM, Shalin Shekhar Mangar wrote:
>>
>>> +1 for committing it.
>>>
>>> Spring may be a pretty big undertaking for which we are not ready at
>>> this point in time. This patch should be incorporated in 1.3 so that
>>> at least the new features can take advantage of the simpler style.  
>>> I'd
>>> even go as far as to suggest giving a uniform look to the entire
>>> solrconfig.xml if possible.
>>>
>>> On Sat, Jul 12, 2008 at 10:03 PM, Yonik Seeley <yo...@apache.org>  
>>> wrote:
>>>>
>>>> I could go either way on this....
>>>> I agree with Grant that the "right" way to do things is to use
>>>> Spring... but that is in the future.  Noble already has the code,  
>>>> so
>>>> the issue is to commit now or not.
>>>> I don't care much about getting an XSD for solrconfig myself, but  
>>>> others
>>>> may...
>>>>
>>>> Anyone else have thoughts on this?
>>>> -Yonik
>>>>
>>>> On Fri, Jul 4, 2008 at 11:54 AM, Chris Hostetter
>>>> <ho...@fucit.org> wrote:
>>>>>
>>>>> : It is very hard to validate a config purely using an XSD. We  
>>>>> have to
>>>>> : rely on the
>>>>> : components themselves to do a validation and I guess it is fine.
>>>>>
>>>>> agreed .. but it would be nice if (someday) you can at least  
>>>>> check that
>>>>> a
>>>>> config is syntactically correct without running Solr ... an XSD  
>>>>> can help
>>>>> with that.
>>>>>
>>>>> : user every day. According to me the user experience is the most
>>>>> : important thing. I don't really
>>>>> : care how many extra lines of code I write to achieve that
>>>>>
>>>>> I agree ... i'm just pointing out trade off.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -Hoss
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Regards,
>>> Shalin Shekhar Mangar.
>>
>>
>
>
>
> -- 
> --Noble Paul


Re: lesser noise in solrconfig.xml

Posted by Noble Paul നോബിള്‍ नोब्ळ् <no...@gmail.com>.
We can choose one clean syntax and stick to it . My preference is to have
<nodename>
 <var1>value-1</var1>
 <var2>value-2</var2>
</nodename>
because this is the most common way I have seen configuration files
instead of.
<lst name="nodename">
 <str name="var1">value-1</var1>
 <str name="var2">value-2</var2>
</lst>

I guess we must be able to stick to one snytax irrespective of the
underlying framework we use because configurations are harder to
change after they have been in use for long.

I personally believe that a framework should not define the
configuration format instead it should enable us to decide on the
format. A lot  of our users are not java users (let alone spring) .
They would prefer to have one conventional format (we are already
using it in many places in solrconfig.xml as in mainIndex etc).




On Mon, Jul 14, 2008 at 9:22 PM, Erik Hatcher
<er...@ehatchersolutions.com> wrote:
> Personally I'm -0 on this one.   Adding another syntax will possibly confuse
> users and us doing mailing list support when presented with bits of the
> config files.   More than one way to do something doesn't seem worthwhile
> here.
>
> While in general I appreciate cleaning up any kind of XML config file syntax
> (by eradicating them altogether ;), I don't think we need to put this in
> Solr right now given we want Solr 2.0 to be Springified (can you even
> imagine how hideous the config will look then?!)
>
> I'm even close to saying -1 on this, but I don't want to throw that much
> weight behind vetoing it - I really do like a cleaner syntax.
>
>        Erik
>
> On Jul 14, 2008, at 11:44 AM, Shalin Shekhar Mangar wrote:
>
>> +1 for committing it.
>>
>> Spring may be a pretty big undertaking for which we are not ready at
>> this point in time. This patch should be incorporated in 1.3 so that
>> at least the new features can take advantage of the simpler style. I'd
>> even go as far as to suggest giving a uniform look to the entire
>> solrconfig.xml if possible.
>>
>> On Sat, Jul 12, 2008 at 10:03 PM, Yonik Seeley <yo...@apache.org> wrote:
>>>
>>> I could go either way on this....
>>> I agree with Grant that the "right" way to do things is to use
>>> Spring... but that is in the future.  Noble already has the code, so
>>> the issue is to commit now or not.
>>> I don't care much about getting an XSD for solrconfig myself, but others
>>> may...
>>>
>>> Anyone else have thoughts on this?
>>> -Yonik
>>>
>>> On Fri, Jul 4, 2008 at 11:54 AM, Chris Hostetter
>>> <ho...@fucit.org> wrote:
>>>>
>>>> : It is very hard to validate a config purely using an XSD. We have to
>>>> : rely on the
>>>> : components themselves to do a validation and I guess it is fine.
>>>>
>>>> agreed .. but it would be nice if (someday) you can at least check that
>>>> a
>>>> config is syntactically correct without running Solr ... an XSD can help
>>>> with that.
>>>>
>>>> : user every day. According to me the user experience is the most
>>>> : important thing. I don't really
>>>> : care how many extra lines of code I write to achieve that
>>>>
>>>> I agree ... i'm just pointing out trade off.
>>>>
>>>>
>>>>
>>>>
>>>> -Hoss
>>>>
>>>>
>>>
>>
>>
>>
>> --
>> Regards,
>> Shalin Shekhar Mangar.
>
>



-- 
--Noble Paul

Re: lesser noise in solrconfig.xml

Posted by Chris Hostetter <ho...@fucit.org>.
I'm a little late to the "should we change this before 1.3" part of the 
discussion, but for hte record i'm -1 for this specific reason...

: Personally I'm -0 on this one.   Adding another syntax will possibly confuse
: users and us doing mailing list support when presented with bits of the config
: files.   More than one way to do something doesn't seem worthwhile here.

...having more then one config syntax is only going to confuse people ... 
even if legacy configs can still be parsed, and even if we change all of 
the example configs, people are still going to be confused.



-Hoss


Re: lesser noise in solrconfig.xml

Posted by Erik Hatcher <er...@ehatchersolutions.com>.
Personally I'm -0 on this one.   Adding another syntax will possibly  
confuse users and us doing mailing list support when presented with  
bits of the config files.   More than one way to do something doesn't  
seem worthwhile here.

While in general I appreciate cleaning up any kind of XML config file  
syntax (by eradicating them altogether ;), I don't think we need to  
put this in Solr right now given we want Solr 2.0 to be Springified  
(can you even imagine how hideous the config will look then?!)

I'm even close to saying -1 on this, but I don't want to throw that  
much weight behind vetoing it - I really do like a cleaner syntax.

	Erik

On Jul 14, 2008, at 11:44 AM, Shalin Shekhar Mangar wrote:

> +1 for committing it.
>
> Spring may be a pretty big undertaking for which we are not ready at
> this point in time. This patch should be incorporated in 1.3 so that
> at least the new features can take advantage of the simpler style. I'd
> even go as far as to suggest giving a uniform look to the entire
> solrconfig.xml if possible.
>
> On Sat, Jul 12, 2008 at 10:03 PM, Yonik Seeley <yo...@apache.org>  
> wrote:
>> I could go either way on this....
>> I agree with Grant that the "right" way to do things is to use
>> Spring... but that is in the future.  Noble already has the code, so
>> the issue is to commit now or not.
>> I don't care much about getting an XSD for solrconfig myself, but  
>> others may...
>>
>> Anyone else have thoughts on this?
>> -Yonik
>>
>> On Fri, Jul 4, 2008 at 11:54 AM, Chris Hostetter
>> <ho...@fucit.org> wrote:
>>>
>>> : It is very hard to validate a config purely using an XSD. We  
>>> have to
>>> : rely on the
>>> : components themselves to do a validation and I guess it is fine.
>>>
>>> agreed .. but it would be nice if (someday) you can at least check  
>>> that a
>>> config is syntactically correct without running Solr ... an XSD  
>>> can help
>>> with that.
>>>
>>> : user every day. According to me the user experience is the most
>>> : important thing. I don't really
>>> : care how many extra lines of code I write to achieve that
>>>
>>> I agree ... i'm just pointing out trade off.
>>>
>>>
>>>
>>>
>>> -Hoss
>>>
>>>
>>
>
>
>
> -- 
> Regards,
> Shalin Shekhar Mangar.


Re: lesser noise in solrconfig.xml

Posted by Shalin Shekhar Mangar <sh...@gmail.com>.
+1 for committing it.

Spring may be a pretty big undertaking for which we are not ready at
this point in time. This patch should be incorporated in 1.3 so that
at least the new features can take advantage of the simpler style. I'd
even go as far as to suggest giving a uniform look to the entire
solrconfig.xml if possible.

On Sat, Jul 12, 2008 at 10:03 PM, Yonik Seeley <yo...@apache.org> wrote:
> I could go either way on this....
> I agree with Grant that the "right" way to do things is to use
> Spring... but that is in the future.  Noble already has the code, so
> the issue is to commit now or not.
> I don't care much about getting an XSD for solrconfig myself, but others may...
>
> Anyone else have thoughts on this?
> -Yonik
>
> On Fri, Jul 4, 2008 at 11:54 AM, Chris Hostetter
> <ho...@fucit.org> wrote:
>>
>> : It is very hard to validate a config purely using an XSD. We have to
>> : rely on the
>> : components themselves to do a validation and I guess it is fine.
>>
>> agreed .. but it would be nice if (someday) you can at least check that a
>> config is syntactically correct without running Solr ... an XSD can help
>> with that.
>>
>> : user every day. According to me the user experience is the most
>> : important thing. I don't really
>> : care how many extra lines of code I write to achieve that
>>
>> I agree ... i'm just pointing out trade off.
>>
>>
>>
>>
>> -Hoss
>>
>>
>



-- 
Regards,
Shalin Shekhar Mangar.

Re: lesser noise in solrconfig.xml

Posted by Yonik Seeley <yo...@apache.org>.
I could go either way on this....
I agree with Grant that the "right" way to do things is to use
Spring... but that is in the future.  Noble already has the code, so
the issue is to commit now or not.
I don't care much about getting an XSD for solrconfig myself, but others may...

Anyone else have thoughts on this?
-Yonik

On Fri, Jul 4, 2008 at 11:54 AM, Chris Hostetter
<ho...@fucit.org> wrote:
>
> : It is very hard to validate a config purely using an XSD. We have to
> : rely on the
> : components themselves to do a validation and I guess it is fine.
>
> agreed .. but it would be nice if (someday) you can at least check that a
> config is syntactically correct without running Solr ... an XSD can help
> with that.
>
> : user every day. According to me the user experience is the most
> : important thing. I don't really
> : care how many extra lines of code I write to achieve that
>
> I agree ... i'm just pointing out trade off.
>
>
>
>
> -Hoss
>
>

Re: lesser noise in solrconfig.xml

Posted by Chris Hostetter <ho...@fucit.org>.
: It is very hard to validate a config purely using an XSD. We have to
: rely on the
: components themselves to do a validation and I guess it is fine.

agreed .. but it would be nice if (someday) you can at least check that a 
config is syntactically correct without running Solr ... an XSD can help 
with that.

: user every day. According to me the user experience is the most
: important thing. I don't really
: care how many extra lines of code I write to achieve that

I agree ... i'm just pointing out trade off.




-Hoss


Re: lesser noise in solrconfig.xml

Posted by Noble Paul നോബിള്‍ नोब्ळ् <no...@gmail.com>.
> while i don't disagree with you that it's not the most compact way to
> express the configuration, one of the main reasons for going this in route
> in the first place was so that (in theory) an XSD could be used to
> validate the structure of the solrconfig.xml, because the "variable"
It is very hard to validate a config purely using an XSD. We have to
rely on the
components themselves to do a validation and I guess it is fine.

> aspects of configuring plugins exists only as attribute values and text --
> not as node names or attribute names (like with Map initialized plugins)
>
> there are still some other places in solrconfig.xml where the XMLB
These things are actually quite simple. It should be that way. Even if
it is hard to write a
component (a one time job) it should not be hard to configure because
it is done by every
user every day. According to me the user experience is the most
important thing. I don't really
care how many extra lines of code I write to achieve that

Actually the NamedList way of doing this is very simple for the
component writer. I get a
NamedList and I know how to consume it. (Actually NamedList is my fav
DataStructure now).
The problem is with the way I express it in XML. If we can simplify
that for the user it would be
happy too.

>
>
>
> -Hoss
>
>



-- 
--Noble Paul

Re: lesser noise in solrconfig.xml

Posted by Chris Hostetter <ho...@fucit.org>.
: All the components initialized by Solr have an init(NamedList args)
: initializer. This leads us to writing the configuration needed for the
: component in the NamedList format. People familiar with Solr may know
: the format but most of what is wrtten is noise than information. For
: users who are not familiar w/ the format find it too difficult to
: understand why they have to write it this way


while i don't disagree with you that it's not the most compact way to 
express the configuration, one of the main reasons for going this in route 
in the first place was so that (in theory) an XSD could be used to 
validate the structure of the solrconfig.xml, because the "variable" 
aspects of configuring plugins exists only as attribute values and text -- 
not as node names or attribute names (like with Map initialized plugins)

there are still some other places in solrconfig.xml where the XML 
structure is variable (cache configs for one) but we (or at least: I) was 
trying to reduce that.



-Hoss


Re: lesser noise in solrconfig.xml

Posted by Yonik Seeley <yo...@apache.org>.
On Thu, Jul 3, 2008 at 9:32 AM, Grant Ingersoll <gs...@apache.org> wrote:
> I agree and your proposal is reasonable, but I hate to think of us inventing
> yet another way to write configuration files and do initialization stuff.  I
> think we really need to consider Solr 2.0 running on Spring.

+1

-Yonik

Re: lesser noise in solrconfig.xml

Posted by Noble Paul നോബിള്‍ नोब्ळ् <no...@gmail.com>.
hi ,
The changes can be minimal. Everything remains same . Just a small
modification for DOMUtil#addToNamedList() method can do the trick. All
the current handlers will work as it is.

I shall file a jira issue for the same.
Let us see what is the best solution

--Noble



On Thu, Jul 3, 2008 at 7:02 PM, Grant Ingersoll <gs...@apache.org> wrote:
> I agree and your proposal is reasonable, but I hate to think of us inventing
> yet another way to write configuration files and do initialization stuff.  I
> think we really need to consider Solr 2.0 running on Spring.  There is just
> no reason why we need to spend so much time and energy on configuration when
> it could be done so much cleaner in an IOC container like Spring.
>
> -Grant
>
> On Jul 3, 2008, at 3:14 AM, Noble Paul നോബിള്‍ नोब्ळ् wrote:
>
>> All the components initialized by Solr have an init(NamedList args)
>> initializer. This leads us to writing the configuration needed for the
>> component in the NamedList format. People familiar with Solr may know
>> the format but most of what is wrtten is noise than information. For
>> users who are not familiar w/ the format find it too difficult to
>> understand why they have to write it this way
>>
>> For example the spellcheckcoponent have a configuration as follows
>> <searchComponent name="spellcheck" class="solr.SpellCheckComponent">
>>     <lst name="spellchecker">
>>        <str name="name">default</str>
>>        <str
>> name="classname">org.apache.solr.spelling.IndexBasedSpellChecker</str>
>>        <str name="field">spell</str>
>>        <str name="spellcheckIndexDir">./spellchecker</str>
>>   </lst>
>> </searchComponent>
>>
>> The most intuitive format for the above configuration would be
>>
>> as follows
>> <searchComponent name="spellcheck" class="solr.SpellCheckComponent">
>>     <spellchecker>
>>       <name>default</name>
>>
>> <classname>org.apache.solr.spelling.IndexBasedSpellChecker</classname>
>>       <field>spell</field>
>>       <spellcheckIndexDir>./spellchecker</spellcheckIndexDir>
>>   </spellchecker>
>> </searchComponent>
>>
>> This enhancement can be done automatically by modifying the DOMUtil
>> class to read the second format to create the namedlist . The new
>> rules for constructing the namedlist can be.
>> * if a tag contains subtags it will be treated <lst>
>> * The tag name will be considered as the 'name'
>> * All the attributes values will be treated as string.
>>
>> This can be further enhanced w/ the following rule
>> * A tag contains attributes will also be a <lst>
>> * Each attribute will be a String value
>> The following can be made equivalent to
>> <searchComponent name="spellcheck" class="solr.SpellCheckComponent">
>> <spellchecker name="default"
>>
>> classname="org.apache.solr.spelling.IndexBasedSpellChecker"
>>                     field="spell"
>>                     spellcheckIndexDir="./spellchecker"/>
>> </searchComponent>
>>
>> The only problem I see w/ this change is that any plugin that relies
>> on the type to be something other than string may fail. But that
>> should not be an excuse for all the new components paying the
>> "NamedList tax"
>> --Noble
>>
>>
>>
>>
>>
>>
>>
>> --
>> --Noble Paul
>
> --------------------------
> Grant Ingersoll
> http://www.lucidimagination.com
>
> Lucene Helpful Hints:
> http://wiki.apache.org/lucene-java/BasicsOfPerformance
> http://wiki.apache.org/lucene-java/LuceneFAQ
>
>
>
>
>
>
>
>



-- 
--Noble Paul

Re: lesser noise in solrconfig.xml

Posted by Grant Ingersoll <gs...@apache.org>.
I agree and your proposal is reasonable, but I hate to think of us  
inventing yet another way to write configuration files and do  
initialization stuff.  I think we really need to consider Solr 2.0  
running on Spring.  There is just no reason why we need to spend so  
much time and energy on configuration when it could be done so much  
cleaner in an IOC container like Spring.

-Grant

On Jul 3, 2008, at 3:14 AM, Noble Paul നോബിള്‍  
नोब्ळ् wrote:

> All the components initialized by Solr have an init(NamedList args)
> initializer. This leads us to writing the configuration needed for the
> component in the NamedList format. People familiar with Solr may know
> the format but most of what is wrtten is noise than information. For
> users who are not familiar w/ the format find it too difficult to
> understand why they have to write it this way
>
> For example the spellcheckcoponent have a configuration as follows
> <searchComponent name="spellcheck" class="solr.SpellCheckComponent">
>      <lst name="spellchecker">
>         <str name="name">default</str>
>         <str  
> name="classname">org.apache.solr.spelling.IndexBasedSpellChecker</str>
>         <str name="field">spell</str>
>         <str name="spellcheckIndexDir">./spellchecker</str>
>    </lst>
> </searchComponent>
>
> The most intuitive format for the above configuration would be
>
> as follows
> <searchComponent name="spellcheck" class="solr.SpellCheckComponent">
>      <spellchecker>
>        <name>default</name>
>        <classname>org.apache.solr.spelling.IndexBasedSpellChecker</ 
> classname>
>        <field>spell</field>
>        <spellcheckIndexDir>./spellchecker</spellcheckIndexDir>
>    </spellchecker>
> </searchComponent>
>
> This enhancement can be done automatically by modifying the DOMUtil
> class to read the second format to create the namedlist . The new
> rules for constructing the namedlist can be.
> * if a tag contains subtags it will be treated <lst>
> * The tag name will be considered as the 'name'
> * All the attributes values will be treated as string.
>
> This can be further enhanced w/ the following rule
> * A tag contains attributes will also be a <lst>
> * Each attribute will be a String value
> The following can be made equivalent to
> <searchComponent name="spellcheck" class="solr.SpellCheckComponent">
> <spellchecker name="default"
>
> classname="org.apache.solr.spelling.IndexBasedSpellChecker"
>                      field="spell"
>                      spellcheckIndexDir="./spellchecker"/>
> </searchComponent>
>
> The only problem I see w/ this change is that any plugin that relies
> on the type to be something other than string may fail. But that
> should not be an excuse for all the new components paying the
> "NamedList tax"
> --Noble
>
>
>
>
>
>
>
> -- 
> --Noble Paul

--------------------------
Grant Ingersoll
http://www.lucidimagination.com

Lucene Helpful Hints:
http://wiki.apache.org/lucene-java/BasicsOfPerformance
http://wiki.apache.org/lucene-java/LuceneFAQ