[
https://issues.apache.org/jira/browse/CASSANDRA-6846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13933619#comment-13933619
]
Tupshin Harper commented on CASSANDRA-6846:
-------------------------------------------
Consider this comment to be an RFC flipping this ticket on its head, and making
it into a meta-ticket for the following:
1) Instead of Cassandra turning into the container, focus on making it easier
to embed Cassandra in your own custom application or container. This would
become a separate independent JIRA, and could be figured out on its own.
2) Focus additional community efforts on figuring out a good and easy to
implement triggers interface to be used as the primary programmatic hook at
ingestion time. Another existing or new ticket would be used for that.
3) Focus additional community efforts on defining a proper UDF (use defined
function) interface using hive-style UDTFs as primary source of inspiration.
This would be the primary programmatic hook for processing results, and could
also be used in conjunction with triggers for inbound processing. There are
already a few tickets around this area, and we would consolidate on one or
create a new one.
4) Define a set of semi-frozen medium level apis (along the lines of what Nate
suggested above) that would be stable for different Zs in X.Y.Z releases, but
free to change in any larger release. The devil is still in the details of
this, but this, too, would be an independent ticket subject to its own debate.
As a result, we would be constantly focusing on CQL as the primary (and really
only) consumable API coming out of Cassandra (as both triggers and UTFs would
be extending CQL). If, however, you needed to do more, that was not possible
with just the triggers and UDF interfaces, you would have to instead embed
Cassandra and would now be responsible for the life-cycle. With additional
power (access to that medium level api), you have incurred the responsibility
of being the container, setting up the environment, and managing the overall
run-time. That's a serious product design question that should not be taken
lightly, but would make sense for a small handful.
I would love to hear if any of the above is a non-starter for any reason, or,
if it were fully realized, if it would be insufficient for anybody's needs.
> 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)
