dsmiley commented on pull request #1684: URL: https://github.com/apache/lucene-solr/pull/1684#issuecomment-685841854
I think use of solr.xml for this is pragmatic/realistic with the Solr we have today. And it's flexible -- can go on the node or in ZK as you desire, and can hold structured information (not just a bag of name-value pairs). This matter can be improved in the future. Some of the other discussion seems to be rooted in a trade-off: assuming there's an efficient plugin (minimally communicates with nodes to get data to make decisions), where does the complexity go relating to concurrency of node communication or knowledge of what nodes to even talk to? If this is in Solr, it can be independently optimized of plugins and makes an autoscaling plugin simpler to write _well_ (because it doesn't need to concern itself with many efficiencies). If we leave the complexity to a plugin writer, Solr is leaner. I don't think this is related to the problems of the previous autoscaling code we got rid of -- I don't think that either path will lead to eventual removal of what's added. A third matter is more a matter of taste on wether it's better/worse to have typed properties (not just in the primitive nature but it's identity / semantic). Trade-offs. I don't like an explosion of classes but I think this is highly mitigated by them being defined as simple inner classes of one outer class, as Ilan has done. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
