Indeed, I reworded (plagiarized) your original proposal; sorry it took me a
full thread loop to grasp it & realize that...
About "comfort", it feels like having one name and multiple aliases per core
would be "easier" to work with than using a path-based identification; since
the path is dependent on the deployment host (path can even be dependent on
an environment variable), using a logical name would preserve more
genericity (replication for instance).
On that premise, there are a few restrictions that {sh,c}ould apply:
0 - Name and aliases reside in a common identifier space; one identifier
uniquely determines a core (can't have the identifier 'core' used a a name
to point to coreA and as an alias to point to coreB)
1 - One core has one unique immutable name
2 - One core may have many aliases
3 - There are only 2 admin commands related to aliases:
3.1 - alias(core, alias): adds an alias to a core, overriding any
existing alias but fails to override a core name.
3.2 - unalias(str); if str is a core name identifier, all its aliases get
deleted, if str is an alias identifer only that alias gets deleted.
4 - Core addressing through URLs/API can use either name or alias (although
using alias is best practice for common -aka non-admin- operations)
Would this still fit the bill? Any obvious (or not so) show-stopper?
I'll try to post a prototype later to see how it goes.
--
View this message in context:
http://www.nabble.com/purpose-of-MultiCore-%22default%22---tp14268755p14413886.html
Sent from the Solr - Dev mailing list archive at Nabble.com.
