First off: Forgive me if my comments/questions are redundent or uninformed bsaed o nthe larger discussion taking place. I have not caught up on the whole thread before replying -- but that's solely based on a lack of time on my part, not a lack of willingness to embrace this change.
>From skimming a handful of messages in this thread, there's one aspect of the discussion -- particularly in the context of "should we or should we not re-use / overlap with 'SolrCloud' terminology" -- that seems (from limited review) to be getting overlooked... Even today, before you start to consider if/what to replace the M & S terms with, we've already reach the point where the replication/IndexFetcher code can use those tems in confusing/missleading ways -- particularly in the context of SolrCloud, recovery, backups, etc... I think a meaningful conversation about retiring the existing terminology should probably take into account at least 3 distinct questions: #1 - what terminology should be used/expected/documented in non-SolrCloud usage of explicitly configuring "classic" ReplicationHandler in solrconfig.xml ? #2 - what terminology should be used in the source code of ReplicationHandler / IndexFetcher related code? #3 - what terminology should be used in the *log* messages of ReplicationHandler / IndexFetcher related code? and (# 3a) should that terminology vary based on the type of cluster and when/why/how the replication code is being used? In reverse order: My personal answers would be: #3a - yes #3 - I think we can & should tweak the replication code to understand the context it's being used in and adjust it's log/error messages accordingly #2 - w/o digging into the code in depth here, i supect something like "remoteSource + localDest" would probably work well in the context of "index fetching" -- or even just simply "fetchSource", w/o any need for a 'slave' term equivilent because the context is usually just "local". ... i don't think there any contexts where it really matters but "replicationSource + replicationDest" code be more generic terms for situations where the code isn't specifically a "I am a core that's doing fetching" context (alternatively: "remoteSource + localDest" could have parity with "localSource + remoteDest" if there are any situations i'm not thinking of where we "push" an index) #1 - this is the least interesting question to me personally (given that we are moving away from it in general in favor of solr cloud), but i think in the context of how the terms are used in solrconfig.xml even the original M & S terms have never really made much sense if you look at where/how they are used in the configuration -- particularly in the context of the "repeater" use case. I would suggest as a straw man replacing the 'name="master"' config block with a 'name="provideSnapshots"' block using hte same options; and replace the 'name="slave"' config block with 'name="fetchSnapshots"' config block, using mostly the same options, except replacing 'masterUrl' with 'sourceUrl'. -Hoss http://www.lucidworks.com/
