[
https://issues.apache.org/jira/browse/THRIFT-876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12904021#action_12904021
]
Todd Lipcon commented on THRIFT-876:
------------------------------------
Where do we draw the line? eg the non-blocking java servers are more
complicated to use than the threadpool server, since they require the framed
transport, etc. But we do include them in the core codebase.
bq. I actually disagree with that. Every feature we add to Thrift makes it less
approachable for everyone who isn't using it. Even if "a couple people" it, we
need to consider the cost for everyone else
How is this so? Having the extra code there (so long as it doesn't drag in
extra external dependencies) doesn't seem like a real problem. How is it any
different if we put it in a "contrib/" directory? In my experience, "contrib"
directories usually become a very strange place - half of the components are
pieces of code that are long since unmaintained (and don't really work), and
others are components that everyone uses every day. This becomes very confusing
for users to separate the things that really work from the things that are
experiments.
> Add SASL support
> ----------------
>
> Key: THRIFT-876
> URL: https://issues.apache.org/jira/browse/THRIFT-876
> Project: Thrift
> Issue Type: New Feature
> Components: Java - Library
> Reporter: Aaron T. Myers
> Assignee: Aaron T. Myers
> Attachments: thrift-876.txt, thrift-876.txt.2
>
>
> It'd be nice if there were some way of securing Thrift communication in a
> pluggable fashion. SASL is the implementation chosen by Hadoop for this.
> Seems like a good option for Thrift, too.
> I'll start with a Java implementation, then move on to support the other
> language bindings.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
