ctubbsii commented on PR #81:
URL: https://github.com/apache/accumulo-proxy/pull/81#issuecomment-1690367143

   > Thanks for the feedback @ctubbsii. I understand your point about not 
reusing the internal Accumulo Thrift utility code for the proxy server, I will 
work with @magrable to address this. I suspect that we'll be duplicating a 
not-insignificant amount of code here, but it will further the goal of 
divorcing the proxy codebase from non-public Accumulo code.
   
   I don't think it needs to duplicate all of Accumulo's boilerplate. The proxy 
might not need all the things that the Accumulo code is doing. If it turns out 
there's a substantial amount of it, we could consider trimming down features, 
or other considerations.
   
   > Would you explain why having multiple thrift protocols for communication 
between a proxy-client and the proxy is a useful or desirable feature? Is there 
any relevant background for how Accumulo itself chooses thrift protocols to use 
that may serve as a precedent for making the decision to choose to support (or 
not support) multiple thrift protocols in the proxy?
   
   The proxy is just supporting the variety of different use cases that Thrift 
itself supports. Whatever Thrift's reasoning is for keeping them all would 
presumably extend to us. So, my argument is more about continuing support for 
an existing feature, unless there's good reason to strip it out, rather than a 
positive argument justifying the the need to support all those protocols. I can 
imagine, though, that some protocols work better with some languages and that 
not all languages support all protocols. While most of the people I know who 
use the proxy use it with Python, the proxy itself isn't Python specific, and 
there might be good reasons some users have for using particular languages with 
particular protocols.
   
   If a good argument can be made that the Accumulo proxy should only support a 
subset of those Thrift features, then I'm open to that, but I would default to 
keeping support for what we have now.


-- 
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.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to