[
https://issues.apache.org/jira/browse/CASSANDRA-2478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13279037#comment-13279037
]
Sylvain Lebresne commented on CASSANDRA-2478:
---------------------------------------------
bq. Support for secure connection(SSL support)
Yes, I completely forgot about that. I meant to mention it. I indeed think we
can do that in a follow up ticket, through that won't be too hard (we don't
plan on supporting StartTLS right?). Anyway, to some extend it's not really
part of the protocol. It's more that we can embed the protocol inside SSL. But
clearly, that's planned.
bq. READY messages body - We may want to reserve some space for server response
I've tried to not add stuffs where I did not know if that would be useful or
not, otherwise you never stop. I mean, things like that can be easily added
later when they become useful (and *we* decide when version 1 of the protocol
is final so we don't have to have figure everything out as soon as this get
committed).
bq. Types in metadata - proposal states it is sent in <string> format, but is
it better to use flags? When custom type is used, we can append FQCN of that
type after the flag
Why not. I'm not sure we'll have a huge saving, and I wonder if tying the
supported native type to the protocol is a good idea. Though as long as we a
way to have custom types we're good so why not. I'll update.
> 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
