[GitHub] [lucene-solr] dsmiley commented on pull request #1684: SOLR-14613: strongly typed placement plugin interface and implementation

[GitBox]

dsmiley commented on pull request #1684:
URL: https://github.com/apache/lucene-solr/pull/1684#issuecomment-686588314


   I am a conflict-avoider (not a good thing) but need to say I fully agree 
with @sigram 's impression of the tone.  I can tell, personally, as a 
subjective measure in how my own body reacts.  When I read conflict, my heart 
starts racing (fight/flight response?), and it started racing on some of 
Noble's comments and Ishan alike.  It can be hard to objectively measure tone; 
I think it's fundamentally subjective, though some particulars we point to can 
be illustrative of behavioral problems.  I will be specific:
   
   @chatman wrote
   > Plugin making concurrent requests is "complicated"? Java is hard, but I 
can help you write a plugin that can make concurrent requests cleanly. Please 
don't pollute solr-core because of your perceived inability to do so cleanly 
from a plugin.
   
   Wow.  I'm not even sure that would be polite to say to a junior engineer 
(that may be presumed to not know concurrency) than a very senior one here.  I 
think you know full well that Ilan doesn't need your help writing concurrent 
code.   Yet why would you offer help?  I think this is a false offer (you know 
Ilan will not take you up on this); -- it's a pejorative offer that belittles 
who you offer it to as being beneath the abilities of your own.  I wonder why 
you would say that?  Maybe you don't believe it's worth it to make it easier 
for plugin writers at the expense of Solr having such concurrent code (i.e. 
where does the concurrency/complexity go) -- fare, but then just say that 
without belittling anyone's intelligence.
   
   At least at the moment it seems we're at a point of better understanding.
   
   p.s. This PR is so big/long that my browser (Safari) struggles to keep up as 
I type here. I copy-paste from a text-editor.t



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

[GitHub] [lucene-solr] dsmiley commented on pull request #1684: SOLR-14613: strongly typed placement plugin interface and implementation

[GitBox]

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