From dev-return-212349-apmail-lucene-dev-archive=lucene.apache.org@lucene.apache.org Fri Jul 10 19:48:50 2015 Return-Path: X-Original-To: apmail-lucene-dev-archive@www.apache.org Delivered-To: apmail-lucene-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 8331518B2A for ; Fri, 10 Jul 2015 19:48:50 +0000 (UTC) Received: (qmail 57014 invoked by uid 500); 10 Jul 2015 19:48:49 -0000 Delivered-To: apmail-lucene-dev-archive@lucene.apache.org Received: (qmail 56942 invoked by uid 500); 10 Jul 2015 19:48:49 -0000 Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@lucene.apache.org Delivered-To: mailing list dev@lucene.apache.org Received: (qmail 56931 invoked by uid 99); 10 Jul 2015 19:48:49 -0000 Received: from Unknown (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 10 Jul 2015 19:48:49 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id EB083C0711 for ; Fri, 10 Jul 2015 19:48:48 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 3.651 X-Spam-Level: *** X-Spam-Status: No, score=3.651 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=3, KAM_INFOUSMEBIZ=0.75, URIBL_BLOCKED=0.001] autolearn=disabled Authentication-Results: spamd4-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-us-west.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id kixAiT10GIgn for ; Fri, 10 Jul 2015 19:48:38 +0000 (UTC) Received: from mail-yk0-f174.google.com (mail-yk0-f174.google.com [209.85.160.174]) by mx1-us-west.apache.org (ASF Mail Server at mx1-us-west.apache.org) with ESMTPS id 2D79720EFB for ; Fri, 10 Jul 2015 19:48:38 +0000 (UTC) Received: by ykeo3 with SMTP id o3so151004284yke.0 for ; Fri, 10 Jul 2015 12:48:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-type; bh=XfwTLkJBiiM+dHIF37orHLmJ8bMIiWZp+S2kMQCA/gs=; b=Jsuf56H99MZklDIBRucWhLSpPCx3rOdQXKUWRTVbhs9qhoG8+JXoJjRPf0lcSbCvgu dh98g6A/RwAsmxtVhi5RvBfJ7NN8L05mIM6Jyl8o4DOZ9hvSSXuv1OVITrIDTOHxjN40 QwMwoFyAuRQQGzv52Bls1S35SOecTDqEACnzLM9TX4td7KMTEdu/jrm8HYwT2K6m3CEo O4aPpML2JPHLUKBOOJHNHJ6UeSp7q2K84D8nItFKBzqhd+bGMbX/elFna7Ovfys1MLhJ pmBW0vW6hTZrSvqQpiYmJKO84x1InaStQ846X8faxuJqWtKih/lWVbPst779yKbDLVLX LFbQ== X-Received: by 10.170.59.194 with SMTP id b185mr25473316ykb.44.1436557717391; Fri, 10 Jul 2015 12:48:37 -0700 (PDT) MIME-Version: 1.0 References: <559E1916.1020309@elyograg.org> <559EAD59.1090703@elyograg.org> <1436472903.3730642.319787825.7A127E1F@webmail.messagingengine.com> In-Reply-To: From: Mark Miller Date: Fri, 10 Jul 2015 19:48:27 +0000 Message-ID: Subject: Re: Is "solrconfig.xml" a potentially misleading filename? To: Lucene Dev Content-Type: multipart/alternative; boundary=001a11398ec271d47c051a8aa8b1 --001a11398ec271d47c051a8aa8b1 Content-Type: text/plain; charset=UTF-8 bq. Then make it accept two names, and start shipping examples with the new name. Old stuff works, new stuff makes sense. That's not all that is involved. When there is so much pointing to solrconfig.xml and you cannot find solrconfig.xml anymore there is added confusion. Doesn't matter if we accept 3 names for the file or not. On Fri, Jul 10, 2015 at 2:15 PM Noble Paul wrote: > A GUI is just one of the multiple interfaces through which a user may > interact with Solr. The API is more important. > > We are starting to move Solr from a config file based system to an API > based system where all that you wish to change in a system is > accessible through the API (I am talking about the config/schema API). > Building a UI is not necessarily important. > > On Fri, Jul 10, 2015 at 10:10 PM, Erick Erickson > wrote: > > So it just occurred to me to ask why stop with renaming? We're going > > around the loop again of "wouldn't it be nice to edit the configs from > > a GUI". Or "a collections like API to manage configs on Zookeeper". > > That got me to wondering if XML is really doing us any favors at this > > point. NOTE: To even suggest this I must be smoking something, but > > would another format avoid that problem? I freely admit I have no > > clue, but... > > > > Whether it's even possible or not to express what we do in the configs > > in, say, JSON I don't know. And whether JSON (or whatever) would avoid > > the security issues I also don't know. My gut feel is that it's a > > massive amount of work and nobody in their right mind would tackle it, > > the rewards are too small for the effort. But I wanted to throw it out > > there. > > > > On Thu, Jul 9, 2015 at 1:15 PM, Upayavira wrote: > >> Then make it accept two names, and start shipping examples with the new > >> name. Old stuff works, new stuff makes sense. > >> > >> Upayavira > >> > >> > >> On Thu, Jul 9, 2015, at 08:47 PM, Mark Miller wrote: > >> > >> It is the wrong name - mostly because it came from a single core > solution. > >> We could change it, but you have to pretty carefully consider how > heavily > >> it's embedded out there now. > >> > >> - Mark > >> > >> On Thu, Jul 9, 2015 at 1:20 PM Shawn Heisey > wrote: > >> > >> On 7/9/2015 10:55 AM, Erick Erickson wrote: > >>> coreconfig.xml has it's own problems in SolrCloud, > >>> collectionconfig seems better. Except in that case > >>> stand-alone Solr doesn't really use collections... > >>> > >>> Siiggghhh. > >> > >> I debated with myself on whether I even wanted to bring this up. > >> Ultimately I decided it would be interesting to discuss, even if we > >> don't take any action. > >> > >> As potential replacements for solrconfig.xml, I find that core.xml or > >> possibly just config.xml are the most appealing ... but the former might > >> be confusing in a SolrCloud context. I'm biased towards cores, because > >> the Solr indexes that I interact with most often are NOT using > >> SolrCloud, and might never use it. I've heard rumblings about SolrCloud > >> becoming the *only* running mode, but that hasn't happened so far. > >> > >> I understand how we got where we are today -- in the early days, Solr > >> only handled one index, so the solrconfig.xml actually did configure all > >> of Solr. > >> > >> Thanks, > >> Shawn > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org > >> For additional commands, e-mail: dev-help@lucene.apache.org > >> > >> > >> -- > >> - Mark > >> about.me/markrmiller > >> > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org > > For additional commands, e-mail: dev-help@lucene.apache.org > > > > > > -- > ----------------------------------------------------- > Noble Paul > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org > For additional commands, e-mail: dev-help@lucene.apache.org > > -- - Mark about.me/markrmiller --001a11398ec271d47c051a8aa8b1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
bq.=C2=A0Then make it accept two names, and start shippin= g examples with the new name. Old stuff works, new stuff makes sense.

That's not all that is involved. When the= re is so much pointing to solrconfig.xml and you cannot find solrconfig.xml= anymore there is added confusion. Doesn't matter if we accept 3 names = for the file or not.

On Fri, Jul 10, 2015 at 2:15 PM Noble Paul <noble.paul@gmail.com> wrote:
A GUI is just one of the multiple interfaces throu= gh which a user may
interact with Solr. The API is more important.

We are starting to move Solr from a config file based system to an API
based system where all that you wish to change in a system is
accessible through the API (I am talking about the config/schema API).
Building a UI is not necessarily important.

On Fri, Jul 10, 2015 at 10:10 PM, Erick Erickson
<erickerick= son@gmail.com> wrote:
> So it just occurred to me to ask why stop with renaming? We're goi= ng
> around the loop again of "wouldn't it be nice to edit the con= figs from
> a GUI". Or "a collections like API to manage configs on Zook= eeper".
> That got me to wondering if XML is really doing us any favors at this<= br> > point. NOTE: To even suggest this I must be smoking something, but
> would another format avoid that problem? I freely admit I have no
> clue, but...
>
> Whether it's even possible or not to express what we do in the con= figs
> in, say, JSON I don't know. And whether JSON (or whatever) would a= void
> the security issues I also don't know. My gut feel is that it'= s a
> massive amount of work and nobody in their right mind would tackle it,=
> the rewards are too small for the effort. But I wanted to throw it out=
> there.
>
> On Thu, Jul 9, 2015 at 1:15 PM, Upayavira <uv@odoko.co.uk> wrote:
>> Then make it accept two names, and start shipping examples with th= e new
>> name. Old stuff works, new stuff makes sense.
>>
>> Upayavira
>>
>>
>> On Thu, Jul 9, 2015, at 08:47 PM, Mark Miller wrote:
>>
>> It is the wrong name - mostly because it came from a single core s= olution.
>> We could change it, but you have to pretty carefully consider how = heavily
>> it's embedded out there now.
>>
>> - Mark
>>
>> On Thu, Jul 9, 2015 at 1:20 PM Shawn Heisey <apache@elyograg.org> wrote: >>
>> On 7/9/2015 10:55 AM, Erick Erickson wrote:
>>> coreconfig.xml has it's own problems in SolrCloud,
>>> collectionconfig seems better. Except in that case
>>> stand-alone Solr doesn't really use collections...
>>>
>>> Siiggghhh.
>>
>> I debated with myself on whether I even wanted to bring this up. >> Ultimately I decided it would be interesting to discuss, even if w= e
>> don't take any action.
>>
>> As potential replacements for solrconfig.xml, I find that core.xml= or
>> possibly just config.xml are the most appealing ... but the former= might
>> be confusing in a SolrCloud context.=C2=A0 I'm biased towards = cores, because
>> the Solr indexes that I interact with most often are NOT using
>> SolrCloud, and might never use it.=C2=A0 I've heard rumblings = about SolrCloud
>> becoming the *only* running mode, but that hasn't happened so = far.
>>
>> I understand how we got where we are today -- in the early days, S= olr
>> only handled one index, so the solrconfig.xml actually did configu= re all
>> of Solr.
>>
>> Thanks,
>> Shawn
>>
>>
>> ------------------------------------------------------------------= ---
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>
>> --
>> - Mark
>> about.me/markrmiller
>>
>>
>
> ---------------------------------------------------------------------<= br> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>



--
-----------------------------------------------------
Noble Paul

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

--
- Mark=C2= =A0 --001a11398ec271d47c051a8aa8b1--