On Tue, Jul 15, 2008 at 12:12 AM, Erik Hatcher <[EMAIL PROTECTED]> 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 >> <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 >>>>> <[EMAIL PROTECTED]> 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
