Subject: Solr Admin UI Refresh 2020

While running it in an external node does ensure separability, I don't
think it does a good job of addressing my other point of not needing to
manage a 3rd server. It's still a server if it's started by java, and one
still has to ensure it exists, and it will be extra hard to figure out how
to configure it if started by Solr.

I'm strongly in favor of us having a UI from my perspective as a consultant
it makes discovery of things like their startup parameters and directories
and such very easy (just go to front page of the admin screen), and it's so
much easier to get a customer with security concerns and strict controls on
who can access what (think banks, military, etc) to share a web session
where they drive the UI than to get direct access to machines. It'll be a
lot slower and much lower service to be making people wait while I craft
curl statements to paste into the web session (and then fix the inevitable
typos, or detect when they missed the last char of what I pasted, etc...).

I definitely against Solr spawning some other server (node or otherwise) on
it's own and thereby requiring additional system dependencies, or creating
a second process that needs to be configured and properly secured. To me
that's even worse than requiring the UI to run outside of Solr. We have a
perfectly good web container already, and furthermore there's a much
greater likelihood that maintainers will be facile with java/j2ee than
anything else (IMHO). It's great if the framework we choose uses little or
no JSP/Servlet and is modernized with a 100% javascript, templated etc.
front end, but the back end should be java/jetty because we've got lots of
java folks.

If the back end matters deeply then you're not really programming to
MVC/REST style...

So there's another $0.02 :) and if you're not careful I'll give you an
entire nickle's worth of ways people misuse/misunderstand the term REST :)


On Tue, Apr 7, 2020 at 9:06 PM Marcus Eagan <[EMAIL PROTECTED]> wrote: (work) (play)