[
https://issues.apache.org/jira/browse/CASSANDRA-2478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13405935#comment-13405935
]
Sylvain Lebresne commented on CASSANDRA-2478:
---------------------------------------------
bq. All of protocol related classes are placed under
org.apache.cassandra.cql3.transport, but I think it'd be better to keep them
under org.apache.cassandra.transport.
Make sense.
bq. Native transport service starts by default along with thrift service, but
isn't it better to turn off by default to indicate "for developing client only"?
I agree. And in any case, most people won't want to run both server at the same
time anyway, so I've added flag for both thrift and the new native server in
the config file to choose whether to start those. You can still overwrite those
by used startup flags, but I believe most of the time the config setting will
be more convenient. And the default is to not start the native transport by
default while it's still beta.
I've rebased the branch and added the two changes above in
https://github.com/pcmanus/cassandra/commits/2478-3. I also made a small
modification due to a remark made by Norman on github. Taking about that,
@Norman, was that your only remark or are you just not done looking at this?
bq. And not necessary at this time, but it is nice to have unit test like
CliTest, based on debug client.
Not sure what you mean by that.
> 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, cql_binary_protocol-v2
>
>
> 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
