subject:"\[jira\] \[Commented\] \(CASSANDRA\-6846\) Provide standard interface for deep application server integration"


[ 
https://issues.apache.org/jira/browse/CASSANDRA-6846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13933300#comment-13933300
 ] 

Edward Capriolo commented on CASSANDRA-6846:


The current prospective seems to be that ALL the code of cassandra is made to 
serve only the CQL language. Everything is INTERNAL. We should close this 
issue no one is going to allow/support anything like this.

 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)

[jira] [Commented] (CASSANDRA-6846) Provide standard interface for deep application server integration

2014-03-13 Thread Russell Bradberry (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-6846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13933319#comment-13933319
 ] 

Russell Bradberry commented on CASSANDRA-6846:
--

[~gdusbabek] I completely ageree, Riak did something similar by separating the 
core distribution from the storage layer allowing people to use components of 
Riak to build a distributed system of their own.  I'm not saying this is the 
right path for C* but modularizability make everything a little easier, it 
would also open the door for more awesome features in DSE, IMO.


 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)

[jira] [Commented] (CASSANDRA-6846) Provide standard interface for deep application server integration


[ 
https://issues.apache.org/jira/browse/CASSANDRA-6846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13933366#comment-13933366
 ] 

Edward Capriolo commented on CASSANDRA-6846:


[~devdazed]
DSE already does this. (Well at leas this is how brisk worked). Brisk put SOLR 
and Hadoop inside cassandra. Yet at the same time the project is saying that 
CQL is the only use case that will be supported.

 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)

[jira] [Commented] (CASSANDRA-6846) Provide standard interface for deep application server integration

2014-03-13 Thread Russell Bradberry (JIRA)

[
https://issues.apache.org/jira/browse/CASSANDRA-6846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13933380#comment-13933380
]

Russell Bradberry commented on CASSANDRA-6846:
--

[~appodictic] What I'm saying is that if the project were componetized then
there wouldn't be a need to put it INSIDE Cassandra. It would just connect
using the available interface. Want to add SOLR? Just drop a JAR, want to add
Hadoop? Drop a JAR. etc. etc. Rather than having a custom built completely
different project.

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)

[jira] [Commented] (CASSANDRA-6846) Provide standard interface for deep application server integration


[ 
https://issues.apache.org/jira/browse/CASSANDRA-6846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13933404#comment-13933404
 ] 

Tupshin Harper commented on CASSANDRA-6846:
---

You are correct that there is substantial overlap between the needs driving 
this ticket, and the need that has driven some users to embed Cassandra in a 
larger app. I'm currently neutral on whether it be approached from that angle, 
or from the original angle of this ticket (or both). But there is a lot of 
equivalency between the two.

 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)

[jira] [Commented] (CASSANDRA-6846) Provide standard interface for deep application server integration

2014-03-13 Thread Jonathan Ellis (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-6846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13933432#comment-13933432
 ] 

Jonathan Ellis commented on CASSANDRA-6846:
---

bq. DSE already does this. (Well at leas this is how brisk worked).

Brisk embedded the Hadoop jobtracker for a bunch of reasons that ended up not 
being worth the trouble.  (I'm pretty sure the latest DSE moved it back out of 
process.)  But all the actual functionality was done with the public API: 
http://github.com/riptano/brisk

 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)

[jira] [Commented] (CASSANDRA-6846) Provide standard interface for deep application server integration

2014-03-13 Thread Jeremiah Jordan (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-6846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13933433#comment-13933433
 ] 

Jeremiah Jordan commented on CASSANDRA-6846:


Are we building the fastest performant database we can or a development 
platform?  You can't have both.  As to be a development platform you must 
sacrifice many of the optimizations that would be possible otherwise, but would 
break the development platform interface.  Riak went the development platform 
way, which I think was to their detriment as a database.  Having pluggable 
everything stops them from being able to make assumptions about how things work 
in another layer.

 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)

[jira] [Commented] (CASSANDRA-6846) Provide standard interface for deep application server integration

2014-03-13 Thread Nate McCall (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-6846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13933463#comment-13933463
 ] 

Nate McCall commented on CASSANDRA-6846:


[~jjordan] I don't think 'pluggable everything' is the right approach either. 

[~gdusbabek]'s standardization of a few internal APIs feels like the right 
idea here. Facilitating greater hackability does not have to have a negative 
effect on performance. 

 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)

[jira] [Commented] (CASSANDRA-6846) Provide standard interface for deep application server integration

[
https://issues.apache.org/jira/browse/CASSANDRA-6846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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
--

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-6846) Provide standard interface for deep application server integration

2014-03-13 Thread Peter (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-6846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13933467#comment-13933467
 ] 

Peter commented on CASSANDRA-6846:
--

I want Cassandra to be a performant database first. My desire is for easier and 
more friendly query capabilities. I want to be able to queries like 
select col1, col2, col3 from MyColFamily where col1='blah1' or col2='blah2'
select * from MyColFamily2 where col3 IN ('blah4,',blah5','blah6') group by col2
select * from MyColFamily3 where col5 LIKE '%blah' and col8 LIKE 'blah2%'

I don't know which approach is the right way to go, but I do feel discussion 
can help flush out pros/cons. At first I thought about doing all of this on the 
client side by writing a SQL parser, query planner and query optimizer, but it 
would need to be done for every single language. When I ported Hector to C#, I 
thought about implementing a full LINQ implementation so that uses can do more 
complex queries, but then I have two completely different code bases for doing 
similar things. Having some enhancement on the server can reduce the amount 
of work for driver implementators. Another approach would be to use Solr 
libraries to make a custom index, which I'm sure others have thought about 
doing. Then there's approaches like spark/shark, presto, etc.

 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)

[jira] [Commented] (CASSANDRA-6846) Provide standard interface for deep application server integration


[ 
https://issues.apache.org/jira/browse/CASSANDRA-6846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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)

[jira] [Commented] (CASSANDRA-6846) Provide standard interface for deep application server integration


[ 
https://issues.apache.org/jira/browse/CASSANDRA-6846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13933852#comment-13933852
 ] 

Edward Capriolo commented on CASSANDRA-6846:


[~tupshin]
https://www.apache.org/foundation/voting.html

{quote}
but -1 votes are vetos and kill the proposal dead until all vetoers withdraw 
their -1 votes.
{quote}

This has been voted dead.

 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)

[jira] [Commented] (CASSANDRA-6846) Provide standard interface for deep application server integration


[ 
https://issues.apache.org/jira/browse/CASSANDRA-6846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13933865#comment-13933865
 ] 

Tupshin Harper commented on CASSANDRA-6846:
---

I'm not concerned about that. Votes can be changed, and this would be in 
principle, and probably in practice, be a brand new ticket anyway.

Let's focus on the issues at hand, people. :)

 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)

[jira] [Commented] (CASSANDRA-6846) Provide standard interface for deep application server integration


[ 
https://issues.apache.org/jira/browse/CASSANDRA-6846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13933883#comment-13933883
 ] 

Edward Capriolo commented on CASSANDRA-6846:


Your points are great. Although I feel they are practices that Cassandra should 
already be engaged in. 

#2 and #3 are way too high level. Sitting on top of triggers and CQL is hardly 
deep integrations that can already be done client side.

 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)

[jira] [Commented] (CASSANDRA-6846) Provide standard interface for deep application server integration


[ 
https://issues.apache.org/jira/browse/CASSANDRA-6846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13933888#comment-13933888
 ] 

Tupshin Harper commented on CASSANDRA-6846:
---

So let's continue to use this ticket to explore what the gap is between what I 
proposed, and what you see as a minimally viable versions of the need expressed 
by #2 and #3.

 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)

[jira] [Commented] (CASSANDRA-6846) Provide standard interface for deep application server integration

2014-03-13 Thread Russell Bradberry (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-6846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13933893#comment-13933893
 ] 

Russell Bradberry commented on CASSANDRA-6846:
--

[~appodictic]
{quote}
To prevent vetos from being used capriciously, they must be accompanied by a 
technical justification showing why the change is bad (opens a security 
exposure, negatively affects performance, etc. ). A veto without a 
justification is invalid and has no weight.
{quote}

The veto was accompanied only by an opinion, not a technical justification.

 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)

[jira] [Commented] (CASSANDRA-6846) Provide standard interface for deep application server integration


[ 
https://issues.apache.org/jira/browse/CASSANDRA-6846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13933931#comment-13933931
 ] 

Edward Capriolo commented on CASSANDRA-6846:


{quote}
So let's continue to use this ticket to explore what the gap is between what I 
proposed, and what you see as a minimally viable versions of the need expressed 
by #2 and #3.
{quote}

Most of what I want from Cassandra can be achieved by implementing 
IDiskAtomFilter instances directly.

Imagine I want all columns that that have a value that matches a regex. In CQL 
it would be something like this:
{code}
SELECT * FROM TABLE WHERE regex_like(COLUMN_VALUE,'?whateverrevex')==true
{code}
A valid point that this can be done with CQL. I agree, IF I knew how to write 
a query parser, and a planner, antlr and yada yada. I agree it can be done. But 
I do not know that stuff, and what I am talking about is a trivial task when 
your on the server side.

Maybe I want to express this something like this:
{code}
columnFamily.stream( {rowkey: 1}).filter ( 
Pattern(whatever).matches(column.value) );
{code}
That would be a deep integration to me. Living below CQL, give me access to 
the ColumnFamily and get out of my way!






 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)

[jira] [Commented] (CASSANDRA-6846) Provide standard interface for deep application server integration

2014-03-13 Thread Peter (JIRA)

[
https://issues.apache.org/jira/browse/CASSANDRA-6846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13933963#comment-13933963
]

Peter commented on CASSANDRA-6846:
--

Having implemented an expert system shell in the past and a LISP interpreter,
UDF's are good for a class of problems. Where performance really matters, being
able to do it at a lower level definitely gives more options for optimizing
performance. Writing query planners isn't that hard, writing a really good one
is very very hard. Being able to integrate at IDiskAtomFilter level should
give users the ability to optimize for their specific needs.
If we look at RDBMS history, most of them had low level hooks for customers
that needed them. 99% of the users never had to use it, but those that did were
glad it was there. Of course it's also ripe for abuse on benchmarks when
vendors took advantage to game TPC-C.
A really dumb question, how likely is it that IDiskAtomFilter will change? I
took a quick look on github and it looks like it has been fairly stable since
2012. I would imagine if the storage format changes, IDiskAtomFilter would need
to be updated. I ask for a couple of reasons. I'm interesting in implementing
Bitmap indexes for Cassandra. I haven't dug deep enough to know what it would
take to add bitmap indexes. I've been reading over the index code the last 2
weeks in my spare time.

Provide standard interface for deep application server integration
--

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CASSANDRA-6846) Provide standard interface for deep application server integration

2014-03-12 Thread Russell Bradberry (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-6846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13931951#comment-13931951
 ] 

Russell Bradberry commented on CASSANDRA-6846:
--

:+1: I'd like to take it one step further and even make parts of Cassandra, 
like CQL, use the interface as well.  Something of eating one's own dog food.  
That way the interface will grow with the features that are added to things 
like CQL and it won't be a constant battle of Feature X was added to CQL can 
we please get it exposed in the interface

 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
 Fix For: 3.0


 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)

[jira] [Commented] (CASSANDRA-6846) Provide standard interface for deep application server integration

2014-03-12 Thread Nate McCall (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-6846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13931958#comment-13931958
 ] 

Nate McCall commented on CASSANDRA-6846:


In hacking on this stuff in the past, what I would like to see here is 
something(s) wrapping a tighter API around:

- StorageProxy
- StorageService
- Schema
- MigrationManager

Probably missing a few things, but those are the immediate items. None of them 
really move around to much, but having a contract on them or encapsulating them 
would be ideal. 

 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
 Fix For: 3.0


 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)

[jira] [Commented] (CASSANDRA-6846) Provide standard interface for deep application server integration

2014-03-12 Thread Sylvain Lebresne (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-6846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13931987#comment-13931987
 ] 

Sylvain Lebresne commented on CASSANDRA-6846:
-

I'm definitively -1 on putting any type of contract on the internals. They are 
called internals for a reason, and if rewriting it all entirely tomorrow is 
best for Cassandra, we should have the possibility to do so. And if we're 
creating a new abstraction on top of it, well, we're just creating a new API, 
and well, I really thing we should focus on having just one API to Cassandra 
and focus efforts there.

 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)

[jira] [Commented] (CASSANDRA-6846) Provide standard interface for deep application server integration

2014-03-12 Thread Peter (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-6846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13931997#comment-13931997
 ] 

Peter commented on CASSANDRA-6846:
--

In the process of building a temporal database on top of Cassandra, I'd like to 
see something like this to make it easier to do complex queries. Right now our 
schema modeler for plain Cassandra uses both Solr and Cassandra so that we can 
do or disjunction, IN with secondary columns, and like clauses. It would be 
nicer to have something on the serverside so that we can offload this from the 
client. 

 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)

[jira] [Commented] (CASSANDRA-6846) Provide standard interface for deep application server integration

2014-03-12 Thread Nate McCall (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-6846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932040#comment-13932040
 ] 

Nate McCall commented on CASSANDRA-6846:


 I'm definitively -1 on putting any type of contract on the internals. 

We've already done this for years with *MBean for folks' monitoring systems. 
That's really all I meant by contract: we'll make an effort so that this won't 
move around too much, but sometimes it will. 

 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)

[jira] [Commented] (CASSANDRA-6846) Provide standard interface for deep application server integration


[ 
https://issues.apache.org/jira/browse/CASSANDRA-6846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932302#comment-13932302
 ] 

Edward Capriolo commented on CASSANDRA-6846:


@Sylvain Lebresne 
This is a brainstorming ticket. Placing a -1 on a brainstorm session is not 
always constructive I would read:

http://sostark.net/post/4965998605/tina-feys-rules-of-improvisation-that-will-change-your

 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)

[jira] [Commented] (CASSANDRA-6846) Provide standard interface for deep application server integration


[ 
https://issues.apache.org/jira/browse/CASSANDRA-6846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932322#comment-13932322
 ] 

Edward Capriolo commented on CASSANDRA-6846:


One of the things I think we should focus on is limiting the amount of static 
things live in the server. One of the knocks against my groovy ticket was OMG 
people will be able to access all the internals. I think that we could build 
up a system with cleaner abstractions and then there would be less need to 
static singletons all over the code.

 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)

[jira] [Commented] (CASSANDRA-6846) Provide standard interface for deep application server integration


[ 
https://issues.apache.org/jira/browse/CASSANDRA-6846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932348#comment-13932348
 ] 

Edward Capriolo commented on CASSANDRA-6846:


I think the most interesting parts are the IDiskAtom filter and column family. 
These are the interesting things to plug for data.

 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)

[jira] [Commented] (CASSANDRA-6846) Provide standard interface for deep application server integration