[
https://issues.apache.org/jira/browse/CASSANDRA-6846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13933457#comment-13933457
]
Edward Capriolo commented on CASSANDRA-6846:
--------------------------------------------
The dev discussion that prompted this ticket was clear in indicating that the
committers do not want to undertake the support burden of supporting multiple
APIs, t the burden of other transports, or other turing complete plug-ability
ideas.
I agree with them. If the burden of supporting an already working thrift is
deemed not worth it, it is hard to justify the burden of supporting deep server
integration.
If the server only officially supports one true API, this second interface will
end up just like thrift, a second class citizen that no one is interested in
supporting. What is the incentive for a developer to expose a very complicated
piece of logic to some plugable interface? None. Just like there was no
incentive to expose features to thrift.
"If any new use cases come to light that can be done with Thrift but not CQL,
we will commit to supporting those in CQL."
All we are attempting to do with this ticket is attempting to replace "Thrift"
with "Deep Application Server Integeration".
DSE is a very successful fork. This work belongs outside the project. As do
many things.
I will open up a fork in a few days and share the details. I think the goal of
the fork will be "say yes". You want to add a memcache compatible API into
cassandra? YES! You want a rest interface ? YES! You want to make the CQL
interface accept CLI commands? YES! You want new thrift methods? Yes!!!! You
want to bring brisk back to life? YES!!! These things will likely never be
wanted by the upstream project. That is fine so be it. Better we move forward
separately.
> Provide standard interface for deep application server integration
> ------------------------------------------------------------------
>
> Key: CASSANDRA-6846
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6846
> Project: Cassandra
> Issue Type: New Feature
> Components: API, Core
> Reporter: Tupshin Harper
> Assignee: Tupshin Harper
> Priority: Minor
> Labels: ponies
>
> Instead of creating a pluggable interface for Thrift, I'd like to create a
> pluggable interface for arbitrary app-server deep integration.
> Inspired by both the existence of intravert-ug, as well as there being a long
> history of various parties embedding tomcat or jetty servlet engines inside
> Cassandra, I'd like to propose the creation an internal somewhat stable
> (versioned?) interface that could allow any app server to achieve deep
> integration with Cassandra, and as a result, these servers could
> 1) host their own apis (REST, for example
> 2) extend core functionality by having limited (see triggers and wide row
> scanners) access to the internals of cassandra
> The hand wavey part comes because while I have been mulling this about for a
> while, I have not spent any significant time into looking at the actual
> surface area of intravert-ug's integration. But, using it as a model, and
> also keeping in minds the general needs of your more traditional servlet/j2ee
> containers, I believe we could come up with a reasonable interface to allow
> any jvm app server to be integrated and maintained in or out of the Cassandra
> tree.
> This would satisfy the needs that many of us (Both Ed and I, for example) to
> have a much greater degree of control over server side execution, and to be
> able to start building much more interestingly (and simply) tiered
> applications.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
