As I'm sure you are all aware, nearly all Solr plugins that are
configurable will receive that configuration in the form of a NamedList,
likely via also implementing NamedListInitializedPlugin.  Analysis
components don't because that's Lucene stuff (no NamedList there) -- they
take a Map constructor argument.  I stumbled on a new breed of plugins
doing something different (was worthy of a dev list discussion; alas).  The
so-called "Container Plugins"[1], (ex: for replica Placement Plugins) have
a unique scheme -- ConfigurablePlugin added via SOLR-14977[2].  I don't see
that it was necessary to have yet another scheme.  Nevertheless, I like it;
it allows typed configuration and automatic XML/JSON conversion to a typed
object.  It feels modern.  I'm raising this here to discuss harmonizing
plugin configuration.  I don't like a fractured disharmonious system of
partially pursued ideas.  Embrace this new idea or extinguish it.  Or a
hybrid.  It warranted a dev list discussion in the first place.

Proposal "A":  Let a plugin author choose between old and new approaches
merely by implementing either interface.  **Don't force the decision by
plugin type; unlike today**.  Imagine a general plugin configuration
initializing mechanism that looks at what the plugin implements
(NamedListInitializedPlugin or ConfigurablePlugin) and configures it
appropriately, whether the input be a NamedList (from XML parsing, most
likely) or some JSON Map -- either way, cross directions?

Proposal "B": Back out ConfigurablePlugin in lieu of
NamedList/NamedListInitializedPlugin for ideal harmony.  *But*, I could
imagine a general utility that a specific plugin author could use to
convert the NamedList to a custom object of their choosing without
requiring the ConfigurablePluginType interface.  Thus at a glance there is
familiarity (NamedList) yet we can still have new toys of object mapping.

Maybe others have ideas / comments.  I think I prefer proposal "B".

[1] We may want to rename "Container Plugin" to "Node Plugin" to use
vernacular understood by Solr users; they don't know what a "container"
is.  Not to mention we regret that "container" name so let's stop using
it?  After all, NodeConfig is called that, not ContainerConfig.
[2]
https://issues.apache.org/jira/browse/SOLR-14977?focusedCommentId=17799932&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17799932

~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley

Reply via email to