Re: Overlapping arguments (SOLR-17383)

[Christos Malliaridis]

Now that we are almost finished with the cleanup of overlapping flags, we
may consider merging some options that serve the same purpose, so that
users don't have to remember multiple options based on the tool / argument
they are using.

I'd like to gather input from all on this topic, since it has a bigger
impact on the user experience if we make any changes.

For your information, the option group with the most variants is the group
that is used to provide the Solr URL. Based on the tool that is used, it is:
- "--solr-url", like in "bin/solr create --solr-url http://localhost:8983
--name collection", which
  - is used most frequently and across multiple tools
  - is usually used in combination with --name / -c for the collection/core
  - is the concatenation of --host, --port and --ssl (theoretically through
the schema) that are present in "bin/solr start ..."
- "--solr-update-url", like in "bin/solr post --solr-update-url
http://localhost:8983/solr/gettingstarted/update *.json", which
  - is a concatenation of --solr-url, --name and a default handler (/update)
  - includes version-specific information of the API (the /solr) that may
require special treatment in the future for backwards compatibility
  - is used only in PostTool
- "--solr-collection-url", like in "bin/solr export --solr-collection-url
http://localhost:8983/solr/gettingstarted --query "*:* -id:test" ", which
  - is a concatenation of --solr-url and --name
  - includes version-specific information of the API (the /solr) that may
require special treatment in the future for backwards compatibility
  - is used in ExportTool and PostLogsTool
- "--base-url", like in "bin/solr-exporter --base-url
http://localhost:8983/solr --config-file ./conf/solr-exporter-config.xml",
which
  - is just --solr-url
  - conflicts with --solr-url in -s for --scrape-interval in all versions
9.X, so it cannot be merged before v10
  - is planned to be removed in v10 and replaced by --solr-url
  - includes version-specific information of the API (the /solr) that may
require special treatment in the future for backwards compatibility

I have created https://issues.apache.org/jira/browse/SOLR-17489 with a
proposal on how to start merging things together into a single option, the
widely used --solr-url and use already known options for providing any
additional information. With a single URL we may extract all information
provided by the URL and override it if the user explicitly provides more
options like the port or the collection.

What are your thoughts about this merge? Should we proceed and "simplify"
things, or do you prefer things like it is now?

Web Socket?

[Gus Heck]

I was traveling, and most of my ongoing work is back on my desktop, so I
entertained myself on a flight by fiddling with an idea that's been
rattling around in the back of my head. It seems like it might be neat to
have a websocket interface to solr, but we definitely don't need it to live
in the main code base since most folks will not use it, so a module seemed
appropriate.

However, I had to do a bit of work to allow a module to start up a
socket, since the current infrastructure (as far as I could tell) only adds
to the classpath. (Possibly I missed something, feel free to point it out)
Although one *could* add an element to solr.xml to start it, it seems
pointless to force the user to declare the module AND edit a config file to
do the thing they will always have to do (start a web server socket) if
they intend to use the module. So I added a module lifecycle, and hacked in
the netty websocket example enough that it starts and stops gracefully and
answers every request with either "parse error" or "not yet implemented"
etc...

Not sure how much or how often I'll get to fiddle with this, but if it
sounds interesting to, you can read it and comment on it here:

https://github.com/apache/solr/pull/2759

-- 
http://www.needhamsoftware.com (work)
https://a.co/d/b2sZLD9 (my fantasy fiction book)