Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Fri, 25 May 2012 19:34:23 +0000 (UTC)
From: "Rick Shaw (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <471411519.3815.1337974463975.JavaMail.jiratomcat@issues-vm>
In-Reply-To: 
 <1815874549.58157.1302800225899.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (CASSANDRA-2478) Custom CQL protocol/transport
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/CASSANDRA-2478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13283703#comment-13283703 ] 

Rick Shaw commented on CASSANDRA-2478:
--------------------------------------

Much of the pressure in the corporate world I live in is from teams that are trying to use JDBC driver for C* in the same fashion and with the same BI, ETL  and statistics tools (Talend, Informatica, Datastage, SPSS, SAS) as they do for relational solutions. Many of these tools are quite comprehensive in the information they can display and use, so they are heavy users of the metadata features of the driver. Returning no data for some functions often causes the tooling to just give up, not to use what they have. 
                
> Custom CQL protocol/transport
> -----------------------------
>
>                 Key: CASSANDRA-2478
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-2478
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: API, Core
>            Reporter: Eric Evans
>            Assignee: Sylvain Lebresne
>            Priority: Minor
>              Labels: cql
>         Attachments: cql_binary_protocol
>
>
> A custom wire protocol would give us the flexibility to optimize for our specific use-cases, and eliminate a troublesome dependency (I'm referring to Thrift, but none of the others would be significantly better).  Additionally, RPC is bad fit here, and we'd do better to move in the direction of something that natively supports streaming.
> I don't think this is as daunting as it might seem initially.  Utilizing an existing server framework like Netty, combined with some copy-and-paste of bits from other FLOSS projects would probably get us 80% of the way there.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira