You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Mark Bennett <ma...@lucidworks.com> on 2013/03/07 23:10:32 UTC
Understanding (and maybe tweaking?`) Solr's odd URLs
As part of making Solr easier to use for new developers, one of the JIRA's I had filed was:
SOLR-4431: Developer Curb Appeal: easier URL to get to Cloud UI
https://issues.apache.org/jira/browse/SOLR-4431
I've been trying to understand why we have such odd URLs in the first place, and could they be simplified?
I'm talking about URLs like:
http://localhost:8983/solr/#/
http://localhost:8983/solr/#/~cores
http://localhost:8983/solr/#/~cloud
I'm sure there's logical reasons for all of this, but I've had trouble finding the original discussion threads on Google (terms like Solr and URL have huge match sets)
I looked around Solr's web.xml file and I see some references to # and ~, but it doesn't really explain it, and there's a comment ("Remove in Solr 5.0") that applies to at least one of the mappings; I wasn't sure of the scope.
Specific questions:
* I assume this was discussed, maybe in JIRA? I was looking for the original threads
* or, Why was this done?
* Did it strike anybody as odd at that time?
* Is this changing in Solr 5? If so, to what?
* Or, could it be easily changed to remove "#/~" parts? (I imagine each character has it's own reason for existing)
So ideally it'd be:
http://localhost:8983/solr/cores
http://localhost:8983/solr/cloud
* If it can't be easily changed due to some architectural issue, could we add some simple redirects to the web.xml file? (Even if we did change the URLs, we'd probably want redirects to preserve the old URLs for a while)
* Could we add web.xml rules to allow for Solr to be the root app?
So in default Jetty:
http://localhost:8983/admin
http://localhost:8983/cores
http://localhost:8983/cloud
http://localhost:8983/search/collection1?q=...
I suspect the current URL structure is there for very good reasons, and seemed like a good idea a few years ago. And I imagine somebody might have even said "nobody types in URLs, they just bookmark everything!". But developers and admins DO type in URLs all the time, and making things easier for new developers is really important. And remember #'s and ~'s if you don't use the tool every single day seems like a needless hassle.
Is there some reasonable compromise here, maybe just with redirects, to make Solr URL's really simple?
Thanks for any info or links or comments!
Mark
--
Mark Bennett / LucidWorks: Search & Big Data / mark.bennett@lucidworks.com
Office: 408-898-4201 / Telecommute: 408-733-0387 / Cell: 408-829-6513
Re: Understanding (and maybe tweaking?`) Solr's odd URLs
Posted by Mark Bennett <ma...@lucidworks.com>.
On Mar 11, 2013, at 2:16 PM, Stefan Matheis <ma...@gmail.com> wrote:
>
> On Monday, March 11, 2013 at 8:27 PM, Mark Bennett wrote:
>> One benefit of this is that, if we ever need to change the implementation for the full form URLs, the short ones could be made to still work (redirect to the new form), and therefore links in documentation, online, etc wouldn't needed as much editing.
>>
>> [..]
>>
>> So, thoughts on shortcut URLs?
> I'm actually a bit "yes, why not"
Yah! Ignore rest of sentence!!! ;-)
> .. but i'm not yet completely sold. i mean, the point with the documentation is fine .. but that's it, more or less, isn't it?
Also "muscle memory" for folks who use Solr all the time. And videos, etc. Short entry URLs help everybody.
>
> If we try to promote those urls as well in the UI itself
I wasn't specifically lobbying for that. I'm fine to have the very first short URL go to the long one and then be done with it.
My theory being once you're in the UI then it's not as big of a deal.
> (otherwise, my guess would be that people don't really remember them) you have to deal with two urls .. the current one you have in your browser and the other one which would be titled as .. "permalink", kind of?
A simple rule could be "short URLs always redirect to the long / correct URLL" (which may change version to version)
And use a 301 or 302, whatever the web gods think is correct.
>
> On Monday, March 11, 2013 at 8:27 PM, Mark Bennett wrote:
>> Ideally, if running in cloud mode, / would take you to an admin that shows that, but there also needs to be links back to admin for the node you've connected to.
>
>
> I'm not sure if i get you here? links back to which node? you mean, if you switch from one instance to another, because you followed the links in the cloud-graph?
Few things:
1: Even when I'm looking at a cloud admin screen, that was rendered by one specific machine, so a link to *that* machine is nice.
2: Generally a link to any of the nodes listed, but there needs to be a link back to cloud view (I logged a JIRA on that)
3: For extra credit, it'd be nice to have a link back to the machine I started at, or even some type of breadcrumb thing?, but not sure there's a compelling reason to do that.
>
> Stefan
>
>
> On Monday, March 11, 2013 at 8:27 PM, Mark Bennett wrote:
>
>> Stefan,
>>
>> Thanks for the info, and congrats on your new gig.
>>
>> I figured there were logical explanations for such all of it, sounds like there is. And generally once you're in the UI, there's not problem with somewhat odd URLs.
>>
>> Plan B was just to allow for shorthand URLs that would redirect to the full URLs.
>>
>> / to solr admin
>>
>> /cloud to cloud
>>
>> /collectionname to that collection
>>
>> /search/collname to …./select, etc.
>>
>> One benefit of this is that, if we ever need to change the implementation for the full form URLs, the short ones could be made to still work (redirect to the new form), and therefore links in documentation, online, etc wouldn't needed as much editing.
>>
>> Ideally, if running in cloud mode, / would take you to an admin that shows that, but there also needs to be links back to admin for the node you've connected to.
>>
>> So, thoughts on shortcut URLs?
>>
>>
>> On Mar 8, 2013, at 2:36 AM, Stefan Matheis <matheis.stefan@gmail.com (mailto:matheis.stefan@gmail.com)> wrote:
>>> Hey Mark
>>>
>>> I'm a bit late on your issues, but after the vacation things got a little busy …
>>>
>>> Hoss already explained a few things in his comment (https://issues.apache.org/jira/browse/SOLR-4431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13596596#comment-13596596) on SOLR-4431
>>>
>>> I'll try to bring a few additional thoughts: It all started with SOLR-2399, moving the UI to a single-page app .. avoiding the (at this time) current situation having multiple sites .. each for one core, so you had multiple places where you could ask solr for its information about threads .. but they are never really core-related, it's kind of "meta-information" which is valid for the whole instance.
>>>
>>> The page is using sammyjs (http://sammyjs.org/) as Framework, and therefore includes the # in the url. Like hoss already explained, everything after the # isn't sent to the server and can therefore directly be controlled on the client-side in your browser.
>>>
>>> Because i don't really know which browsers users use for the UI (and it seems there are at least a few IE-Users out there ;o) i tried to avoid using fancy stuff which will only work in newer browsers. Having said that .. in theory you can avoid those # - but therefore you have to ensure that every single url which is used by the UI is correctly handled by the Server (think of switching details on the plugin-site)
>>>
>>> Using the Tilde was a try to distinguish between stuff that is core- and non-core related, otherwise (also like hoss already said) there would be a conflict if the user uses (for whatever reason) a core named java-properties, threads and so on.
>>>
>>> the "/solr" part is based on the fact, that you could install multiple webapps into a servlet-container and they have to be mounted on a path. that could clearly be root (/), but i guess there are reasons why does wasn't used in the example package - but the UI will work anyway, because the information on which path solr is running is inject in the page while its initially loaded
>>>
>>> If i did miss some questions you'd like to know things about .. just let me know :)
>>>
>>> Stefan
>>>
>>>
>>> On Thursday, March 7, 2013 at 11:10 PM, Mark Bennett wrote:
>>>
>>>> As part of making Solr easier to use for new developers, one of the JIRA's I had filed was:
>>>>
>>>> SOLR-4431: Developer Curb Appeal: easier URL to get to Cloud UI
>>>> https://issues.apache.org/jira/browse/SOLR-4431
>>>>
>>>> I've been trying to understand why we have such odd URLs in the first place, and could they be simplified?
>>>>
>>>> I'm talking about URLs like:
>>>> http://localhost:8983/solr/#/
>>>> http://localhost:8983/solr/#/~cores
>>>> http://localhost:8983/solr/#/~cloud
>>>>
>>>>
>>>> I'm sure there's logical reasons for all of this, but I've had trouble finding the original discussion threads on Google (terms like Solr and URL have huge match sets)
>>>>
>>>> I looked around Solr's web.xml (http://web.xml) file and I see some references to # and ~, but it doesn't really explain it, and there's a comment ("Remove in Solr 5.0") that applies to at least one of the mappings; I wasn't sure of the scope.
>>>>
>>>> Specific questions:
>>>>
>>>> * I assume this was discussed, maybe in JIRA? I was looking for the original threads
>>>> * or, Why was this done?
>>>>
>>>> * Did it strike anybody as odd at that time?
>>>>
>>>> * Is this changing in Solr 5? If so, to what?
>>>>
>>>> * Or, could it be easily changed to remove "#/~" parts? (I imagine each character has it's own reason for existing)
>>>> So ideally it'd be:
>>>> http://localhost:8983/solr/cores
>>>> http://localhost:8983/solr/cloud
>>>>
>>>>
>>>> * If it can't be easily changed due to some architectural issue, could we add some simple redirects to the web.xml (http://web.xml) file? (Even if we did change the URLs, we'd probably want redirects to preserve the old URLs for a while)
>>>>
>>>> * Could we add web.xml (http://web.xml) rules to allow for Solr to be the root app?
>>>> So in default Jetty:
>>>> http://localhost:8983/admin
>>>> http://localhost:8983/cores
>>>> http://localhost:8983/cloud
>>>>
>>>> http://localhost:8983/search/collection1?q=...
>>>>
>>>>
>>>> I suspect the current URL structure is there for very good reasons, and seemed like a good idea a few years ago. And I imagine somebody might have even said "nobody types in URLs, they just bookmark everything!". But developers and admins DO type in URLs all the time, and making things easier for new developers is really important. And remember #'s and ~'s if you don't use the tool every single day seems like a needless hassle.
>>>>
>>>> Is there some reasonable compromise here, maybe just with redirects, to make Solr URL's really simple?
>>>>
>>>> Thanks for any info or links or comments!
>>>> Mark
>>>>
>>>> --
>>>> Mark Bennett / LucidWorks: Search & Big Data / mark.bennett@lucidworks.com (mailto:mark.bennett@lucidworks.com)
>>>> Office: 408-898-4201 / Telecommute: 408-733-0387 / Cell: 408-829-6513
>>>
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org (mailto:dev-unsubscribe@lucene.apache.org)
>>> For additional commands, e-mail: dev-help@lucene.apache.org (mailto:dev-help@lucene.apache.org)
>>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Understanding (and maybe tweaking?`) Solr's odd URLs
Posted by Stefan Matheis <ma...@gmail.com>.
On Monday, March 11, 2013 at 8:27 PM, Mark Bennett wrote:
> Thanks for the info, and congrats on your new gig.
Thanks Mark :)
On Monday, March 11, 2013 at 8:27 PM, Mark Bennett wrote:
> One benefit of this is that, if we ever need to change the implementation for the full form URLs, the short ones could be made to still work (redirect to the new form), and therefore links in documentation, online, etc wouldn't needed as much editing.
>
> [..]
>
> So, thoughts on shortcut URLs?
I'm actually a bit "yes, why not" .. but i'm not yet completely sold. i mean, the point with the documentation is fine .. but that's it, more or less, isn't it?
If we try to promote those urls as well in the UI itself (otherwise, my guess would be that people don't really remember them) you have to deal with two urls .. the current one you have in your browser and the other one which would be titled as .. "permalink", kind of?
On Monday, March 11, 2013 at 8:27 PM, Mark Bennett wrote:
> Ideally, if running in cloud mode, / would take you to an admin that shows that, but there also needs to be links back to admin for the node you've connected to.
I'm not sure if i get you here? links back to which node? you mean, if you switch from one instance to another, because you followed the links in the cloud-graph?
Stefan
On Monday, March 11, 2013 at 8:27 PM, Mark Bennett wrote:
> Stefan,
>
> Thanks for the info, and congrats on your new gig.
>
> I figured there were logical explanations for such all of it, sounds like there is. And generally once you're in the UI, there's not problem with somewhat odd URLs.
>
> Plan B was just to allow for shorthand URLs that would redirect to the full URLs.
>
> / to solr admin
>
> /cloud to cloud
>
> /collectionname to that collection
>
> /search/collname to …./select, etc.
>
> One benefit of this is that, if we ever need to change the implementation for the full form URLs, the short ones could be made to still work (redirect to the new form), and therefore links in documentation, online, etc wouldn't needed as much editing.
>
> Ideally, if running in cloud mode, / would take you to an admin that shows that, but there also needs to be links back to admin for the node you've connected to.
>
> So, thoughts on shortcut URLs?
>
>
> On Mar 8, 2013, at 2:36 AM, Stefan Matheis <matheis.stefan@gmail.com (mailto:matheis.stefan@gmail.com)> wrote:
> > Hey Mark
> >
> > I'm a bit late on your issues, but after the vacation things got a little busy …
> >
> > Hoss already explained a few things in his comment (https://issues.apache.org/jira/browse/SOLR-4431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13596596#comment-13596596) on SOLR-4431
> >
> > I'll try to bring a few additional thoughts: It all started with SOLR-2399, moving the UI to a single-page app .. avoiding the (at this time) current situation having multiple sites .. each for one core, so you had multiple places where you could ask solr for its information about threads .. but they are never really core-related, it's kind of "meta-information" which is valid for the whole instance.
> >
> > The page is using sammyjs (http://sammyjs.org/) as Framework, and therefore includes the # in the url. Like hoss already explained, everything after the # isn't sent to the server and can therefore directly be controlled on the client-side in your browser.
> >
> > Because i don't really know which browsers users use for the UI (and it seems there are at least a few IE-Users out there ;o) i tried to avoid using fancy stuff which will only work in newer browsers. Having said that .. in theory you can avoid those # - but therefore you have to ensure that every single url which is used by the UI is correctly handled by the Server (think of switching details on the plugin-site)
> >
> > Using the Tilde was a try to distinguish between stuff that is core- and non-core related, otherwise (also like hoss already said) there would be a conflict if the user uses (for whatever reason) a core named java-properties, threads and so on.
> >
> > the "/solr" part is based on the fact, that you could install multiple webapps into a servlet-container and they have to be mounted on a path. that could clearly be root (/), but i guess there are reasons why does wasn't used in the example package - but the UI will work anyway, because the information on which path solr is running is inject in the page while its initially loaded
> >
> > If i did miss some questions you'd like to know things about .. just let me know :)
> >
> > Stefan
> >
> >
> > On Thursday, March 7, 2013 at 11:10 PM, Mark Bennett wrote:
> >
> > > As part of making Solr easier to use for new developers, one of the JIRA's I had filed was:
> > >
> > > SOLR-4431: Developer Curb Appeal: easier URL to get to Cloud UI
> > > https://issues.apache.org/jira/browse/SOLR-4431
> > >
> > > I've been trying to understand why we have such odd URLs in the first place, and could they be simplified?
> > >
> > > I'm talking about URLs like:
> > > http://localhost:8983/solr/#/
> > > http://localhost:8983/solr/#/~cores
> > > http://localhost:8983/solr/#/~cloud
> > >
> > >
> > > I'm sure there's logical reasons for all of this, but I've had trouble finding the original discussion threads on Google (terms like Solr and URL have huge match sets)
> > >
> > > I looked around Solr's web.xml (http://web.xml) file and I see some references to # and ~, but it doesn't really explain it, and there's a comment ("Remove in Solr 5.0") that applies to at least one of the mappings; I wasn't sure of the scope.
> > >
> > > Specific questions:
> > >
> > > * I assume this was discussed, maybe in JIRA? I was looking for the original threads
> > > * or, Why was this done?
> > >
> > > * Did it strike anybody as odd at that time?
> > >
> > > * Is this changing in Solr 5? If so, to what?
> > >
> > > * Or, could it be easily changed to remove "#/~" parts? (I imagine each character has it's own reason for existing)
> > > So ideally it'd be:
> > > http://localhost:8983/solr/cores
> > > http://localhost:8983/solr/cloud
> > >
> > >
> > > * If it can't be easily changed due to some architectural issue, could we add some simple redirects to the web.xml (http://web.xml) file? (Even if we did change the URLs, we'd probably want redirects to preserve the old URLs for a while)
> > >
> > > * Could we add web.xml (http://web.xml) rules to allow for Solr to be the root app?
> > > So in default Jetty:
> > > http://localhost:8983/admin
> > > http://localhost:8983/cores
> > > http://localhost:8983/cloud
> > >
> > > http://localhost:8983/search/collection1?q=...
> > >
> > >
> > > I suspect the current URL structure is there for very good reasons, and seemed like a good idea a few years ago. And I imagine somebody might have even said "nobody types in URLs, they just bookmark everything!". But developers and admins DO type in URLs all the time, and making things easier for new developers is really important. And remember #'s and ~'s if you don't use the tool every single day seems like a needless hassle.
> > >
> > > Is there some reasonable compromise here, maybe just with redirects, to make Solr URL's really simple?
> > >
> > > Thanks for any info or links or comments!
> > > Mark
> > >
> > > --
> > > Mark Bennett / LucidWorks: Search & Big Data / mark.bennett@lucidworks.com (mailto:mark.bennett@lucidworks.com)
> > > Office: 408-898-4201 / Telecommute: 408-733-0387 / Cell: 408-829-6513
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org (mailto:dev-unsubscribe@lucene.apache.org)
> > For additional commands, e-mail: dev-help@lucene.apache.org (mailto:dev-help@lucene.apache.org)
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Understanding (and maybe tweaking?`) Solr's odd URLs
Posted by Mark Bennett <ma...@lucidworks.com>.
Stefan,
Thanks for the info, and congrats on your new gig.
I figured there were logical explanations for such all of it, sounds like there is. And generally once you're in the UI, there's not problem with somewhat odd URLs.
Plan B was just to allow for shorthand URLs that would redirect to the full URLs.
/ to solr admin
/cloud to cloud
/collectionname to that collection
/search/collname to …./select, etc.
One benefit of this is that, if we ever need to change the implementation for the full form URLs, the short ones could be made to still work (redirect to the new form), and therefore links in documentation, online, etc wouldn't needed as much editing.
Ideally, if running in cloud mode, / would take you to an admin that shows that, but there also needs to be links back to admin for the node you've connected to.
So, thoughts on shortcut URLs?
On Mar 8, 2013, at 2:36 AM, Stefan Matheis <ma...@gmail.com> wrote:
> Hey Mark
>
> I'm a bit late on your issues, but after the vacation things got a little busy …
>
> Hoss already explained a few things in his comment (https://issues.apache.org/jira/browse/SOLR-4431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13596596#comment-13596596) on SOLR-4431
>
> I'll try to bring a few additional thoughts: It all started with SOLR-2399, moving the UI to a single-page app .. avoiding the (at this time) current situation having multiple sites .. each for one core, so you had multiple places where you could ask solr for its information about threads .. but they are never really core-related, it's kind of "meta-information" which is valid for the whole instance.
>
> The page is using sammyjs (http://sammyjs.org/) as Framework, and therefore includes the # in the url. Like hoss already explained, everything after the # isn't sent to the server and can therefore directly be controlled on the client-side in your browser.
>
> Because i don't really know which browsers users use for the UI (and it seems there are at least a few IE-Users out there ;o) i tried to avoid using fancy stuff which will only work in newer browsers. Having said that .. in theory you can avoid those # - but therefore you have to ensure that every single url which is used by the UI is correctly handled by the Server (think of switching details on the plugin-site)
>
> Using the Tilde was a try to distinguish between stuff that is core- and non-core related, otherwise (also like hoss already said) there would be a conflict if the user uses (for whatever reason) a core named java-properties, threads and so on.
>
> the "/solr" part is based on the fact, that you could install multiple webapps into a servlet-container and they have to be mounted on a path. that could clearly be root (/), but i guess there are reasons why does wasn't used in the example package - but the UI will work anyway, because the information on which path solr is running is inject in the page while its initially loaded
>
> If i did miss some questions you'd like to know things about .. just let me know :)
>
> Stefan
>
>
> On Thursday, March 7, 2013 at 11:10 PM, Mark Bennett wrote:
>
>> As part of making Solr easier to use for new developers, one of the JIRA's I had filed was:
>>
>> SOLR-4431: Developer Curb Appeal: easier URL to get to Cloud UI
>> https://issues.apache.org/jira/browse/SOLR-4431
>>
>> I've been trying to understand why we have such odd URLs in the first place, and could they be simplified?
>>
>> I'm talking about URLs like:
>> http://localhost:8983/solr/#/
>> http://localhost:8983/solr/#/~cores
>> http://localhost:8983/solr/#/~cloud
>>
>>
>> I'm sure there's logical reasons for all of this, but I've had trouble finding the original discussion threads on Google (terms like Solr and URL have huge match sets)
>>
>> I looked around Solr's web.xml (http://web.xml) file and I see some references to # and ~, but it doesn't really explain it, and there's a comment ("Remove in Solr 5.0") that applies to at least one of the mappings; I wasn't sure of the scope.
>>
>> Specific questions:
>>
>> * I assume this was discussed, maybe in JIRA? I was looking for the original threads
>> * or, Why was this done?
>>
>> * Did it strike anybody as odd at that time?
>>
>> * Is this changing in Solr 5? If so, to what?
>>
>> * Or, could it be easily changed to remove "#/~" parts? (I imagine each character has it's own reason for existing)
>> So ideally it'd be:
>> http://localhost:8983/solr/cores
>> http://localhost:8983/solr/cloud
>>
>>
>> * If it can't be easily changed due to some architectural issue, could we add some simple redirects to the web.xml (http://web.xml) file? (Even if we did change the URLs, we'd probably want redirects to preserve the old URLs for a while)
>>
>> * Could we add web.xml (http://web.xml) rules to allow for Solr to be the root app?
>> So in default Jetty:
>> http://localhost:8983/admin
>> http://localhost:8983/cores
>> http://localhost:8983/cloud
>>
>> http://localhost:8983/search/collection1?q=...
>>
>>
>> I suspect the current URL structure is there for very good reasons, and seemed like a good idea a few years ago. And I imagine somebody might have even said "nobody types in URLs, they just bookmark everything!". But developers and admins DO type in URLs all the time, and making things easier for new developers is really important. And remember #'s and ~'s if you don't use the tool every single day seems like a needless hassle.
>>
>> Is there some reasonable compromise here, maybe just with redirects, to make Solr URL's really simple?
>>
>> Thanks for any info or links or comments!
>> Mark
>>
>> --
>> Mark Bennett / LucidWorks: Search & Big Data / mark.bennett@lucidworks.com (mailto:mark.bennett@lucidworks.com)
>> Office: 408-898-4201 / Telecommute: 408-733-0387 / Cell: 408-829-6513
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
Re: Understanding (and maybe tweaking?`) Solr's odd URLs
Posted by Stefan Matheis <ma...@gmail.com>.
Hey Mark
I'm a bit late on your issues, but after the vacation things got a little busy …
Hoss already explained a few things in his comment (https://issues.apache.org/jira/browse/SOLR-4431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13596596#comment-13596596) on SOLR-4431
I'll try to bring a few additional thoughts: It all started with SOLR-2399, moving the UI to a single-page app .. avoiding the (at this time) current situation having multiple sites .. each for one core, so you had multiple places where you could ask solr for its information about threads .. but they are never really core-related, it's kind of "meta-information" which is valid for the whole instance.
The page is using sammyjs (http://sammyjs.org/) as Framework, and therefore includes the # in the url. Like hoss already explained, everything after the # isn't sent to the server and can therefore directly be controlled on the client-side in your browser.
Because i don't really know which browsers users use for the UI (and it seems there are at least a few IE-Users out there ;o) i tried to avoid using fancy stuff which will only work in newer browsers. Having said that .. in theory you can avoid those # - but therefore you have to ensure that every single url which is used by the UI is correctly handled by the Server (think of switching details on the plugin-site)
Using the Tilde was a try to distinguish between stuff that is core- and non-core related, otherwise (also like hoss already said) there would be a conflict if the user uses (for whatever reason) a core named java-properties, threads and so on.
the "/solr" part is based on the fact, that you could install multiple webapps into a servlet-container and they have to be mounted on a path. that could clearly be root (/), but i guess there are reasons why does wasn't used in the example package - but the UI will work anyway, because the information on which path solr is running is inject in the page while its initially loaded
If i did miss some questions you'd like to know things about .. just let me know :)
Stefan
On Thursday, March 7, 2013 at 11:10 PM, Mark Bennett wrote:
> As part of making Solr easier to use for new developers, one of the JIRA's I had filed was:
>
> SOLR-4431: Developer Curb Appeal: easier URL to get to Cloud UI
> https://issues.apache.org/jira/browse/SOLR-4431
>
> I've been trying to understand why we have such odd URLs in the first place, and could they be simplified?
>
> I'm talking about URLs like:
> http://localhost:8983/solr/#/
> http://localhost:8983/solr/#/~cores
> http://localhost:8983/solr/#/~cloud
>
>
> I'm sure there's logical reasons for all of this, but I've had trouble finding the original discussion threads on Google (terms like Solr and URL have huge match sets)
>
> I looked around Solr's web.xml (http://web.xml) file and I see some references to # and ~, but it doesn't really explain it, and there's a comment ("Remove in Solr 5.0") that applies to at least one of the mappings; I wasn't sure of the scope.
>
> Specific questions:
>
> * I assume this was discussed, maybe in JIRA? I was looking for the original threads
> * or, Why was this done?
>
> * Did it strike anybody as odd at that time?
>
> * Is this changing in Solr 5? If so, to what?
>
> * Or, could it be easily changed to remove "#/~" parts? (I imagine each character has it's own reason for existing)
> So ideally it'd be:
> http://localhost:8983/solr/cores
> http://localhost:8983/solr/cloud
>
>
> * If it can't be easily changed due to some architectural issue, could we add some simple redirects to the web.xml (http://web.xml) file? (Even if we did change the URLs, we'd probably want redirects to preserve the old URLs for a while)
>
> * Could we add web.xml (http://web.xml) rules to allow for Solr to be the root app?
> So in default Jetty:
> http://localhost:8983/admin
> http://localhost:8983/cores
> http://localhost:8983/cloud
>
> http://localhost:8983/search/collection1?q=...
>
>
> I suspect the current URL structure is there for very good reasons, and seemed like a good idea a few years ago. And I imagine somebody might have even said "nobody types in URLs, they just bookmark everything!". But developers and admins DO type in URLs all the time, and making things easier for new developers is really important. And remember #'s and ~'s if you don't use the tool every single day seems like a needless hassle.
>
> Is there some reasonable compromise here, maybe just with redirects, to make Solr URL's really simple?
>
> Thanks for any info or links or comments!
> Mark
>
> --
> Mark Bennett / LucidWorks: Search & Big Data / mark.bennett@lucidworks.com (mailto:mark.bennett@lucidworks.com)
> Office: 408-898-4201 / Telecommute: 408-733-0387 / Cell: 408-829-6513
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Understanding (and maybe tweaking?`) Solr's odd URLs
Posted by Mark Miller <ma...@gmail.com>.
Stefan Matheis is likely the guy that knows. Personally I don't have a
problem with those URL's - not really sure how it makes anything more
difficult for developers...
Seems like a low priority change to me that would just break peoples
current bookmarks and such.
- Mark
On Thu, Mar 7, 2013 at 2:10 PM, Mark Bennett
<ma...@lucidworks.com> wrote:
> As part of making Solr easier to use for new developers, one of the JIRA's I
> had filed was:
>
> SOLR-4431: Developer Curb Appeal: easier URL to get to Cloud UI
> https://issues.apache.org/jira/browse/SOLR-4431
>
> I've been trying to understand why we have such odd URLs in the first place,
> and could they be simplified?
>
> I'm talking about URLs like:
> http://localhost:8983/solr/#/
> http://localhost:8983/solr/#/~cores
> http://localhost:8983/solr/#/~cloud
>
> I'm sure there's logical reasons for all of this, but I've had trouble
> finding the original discussion threads on Google (terms like Solr and URL
> have huge match sets)
>
> I looked around Solr's web.xml file and I see some references to # and ~,
> but it doesn't really explain it, and there's a comment ("Remove in Solr
> 5.0") that applies to at least one of the mappings; I wasn't sure of the
> scope.
>
> Specific questions:
>
> * I assume this was discussed, maybe in JIRA? I was looking for the
> original threads
> * or, Why was this done?
>
> * Did it strike anybody as odd at that time?
>
> * Is this changing in Solr 5? If so, to what?
>
> * Or, could it be easily changed to remove "#/~" parts? (I imagine each
> character has it's own reason for existing)
> So ideally it'd be:
> http://localhost:8983/solr/cores
> http://localhost:8983/solr/cloud
>
> * If it can't be easily changed due to some architectural issue, could we
> add some simple redirects to the web.xml file? (Even if we did change the
> URLs, we'd probably want redirects to preserve the old URLs for a while)
>
> * Could we add web.xml rules to allow for Solr to be the root app?
> So in default Jetty:
> http://localhost:8983/admin
> http://localhost:8983/cores
> http://localhost:8983/cloud
> http://localhost:8983/search/collection1?q=...
>
> I suspect the current URL structure is there for very good reasons, and
> seemed like a good idea a few years ago. And I imagine somebody might have
> even said "nobody types in URLs, they just bookmark everything!". But
> developers and admins DO type in URLs all the time, and making things easier
> for new developers is really important. And remember #'s and ~'s if you
> don't use the tool every single day seems like a needless hassle.
>
> Is there some reasonable compromise here, maybe just with redirects, to make
> Solr URL's really simple?
>
> Thanks for any info or links or comments!
> Mark
>
> --
> Mark Bennett / LucidWorks: Search & Big Data / mark.bennett@lucidworks.com
> Office: 408-898-4201 / Telecommute: 408-733-0387 / Cell: 408-829-6513
>
>
>
>
>
>
>
--
- Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Understanding (and maybe tweaking?`) Solr's odd URLs
Posted by Shalin Shekhar Mangar <sh...@gmail.com>.
The navigation between pages of Solr Admin UI is ajax based i.e. the page
is not reloaded. However, to support history (back button functionality),
the URL in the location bar is changed by changing # urls. IIRC, there is
no easy way to change non #-based url in the location bar without forcing
page refresh on certain browsers.
On Fri, Mar 8, 2013 at 3:40 AM, Mark Bennett <ma...@lucidworks.com>wrote:
> As part of making Solr easier to use for new developers, one of the JIRA's
> I had filed was:
>
> SOLR-4431: Developer Curb Appeal: easier URL to get to Cloud UI
> https://issues.apache.org/jira/browse/SOLR-4431
>
> I've been trying to understand why we have such odd URLs in the first
> place, and could they be simplified?
>
> I'm talking about URLs like:
> http://localhost:8983/solr/#/
> http://localhost:8983/solr/#/~cores
> http://localhost:8983/solr/#/~cloud
>
> I'm sure there's logical reasons for all of this, but I've had trouble
> finding the original discussion threads on Google (terms like Solr and URL
> have huge match sets)
>
> I looked around Solr's web.xml file and I see some references to # and ~,
> but it doesn't really explain it, and there's a comment ("Remove in Solr
> 5.0") that applies to at least one of the mappings; I wasn't sure of the
> scope.
>
> Specific questions:
>
> * I assume this was discussed, maybe in JIRA? I was looking for the
> original threads
> * or, Why was this done?
>
> * Did it strike anybody as odd at that time?
>
> * Is this changing in Solr 5? If so, to what?
>
> * Or, could it be easily changed to remove "#/~" parts? (I imagine each
> character has it's own reason for existing)
> So ideally it'd be:
> http://localhost:8983/solr/cores
> http://localhost:8983/solr/cloud
>
> * If it can't be easily changed due to some architectural issue, could we
> add some simple redirects to the web.xml file? (Even if we did change the
> URLs, we'd probably want redirects to preserve the old URLs for a while)
>
> * Could we add web.xml rules to allow for Solr to be the root app?
> So in default Jetty:
> http://localhost:8983/admin
> http://localhost:8983/cores
> http://localhost:8983/cloud
> http://localhost:8983/search/collection1?q=...
>
> I suspect the current URL structure is there for very good reasons, and
> seemed like a good idea a few years ago. And I imagine somebody might have
> even said "nobody types in URLs, they just bookmark everything!". But
> developers and admins DO type in URLs all the time, and making things
> easier for new developers is really important. And remember #'s and ~'s if
> you don't use the tool every single day seems like a needless hassle.
>
> Is there some reasonable compromise here, maybe just with redirects, to
> make Solr URL's really simple?
>
> Thanks for any info or links or comments!
> Mark
>
> --
> Mark Bennett / LucidWorks: Search & Big Data / mark.bennett@lucidworks.com
> Office: 408-898-4201 / Telecommute: 408-733-0387 / Cell: 408-829-6513
>
>
>
>
>
>
>
>
--
Regards,
Shalin Shekhar Mangar.