[
https://issues.apache.org/jira/browse/CASSANDRA-2478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13407415#comment-13407415
]
paul cannon commented on CASSANDRA-2478:
----------------------------------------
I have some input on this too, if it's worth anything. When implementing
servers and clients with this sort of protocol, the biggest headaches I
experience are usually around cross-version compatibility. This draft spec
doesn't allow much in that respect.
As an initial change, could we divorce the versioning for the framing protocol
and the set of actual communication messages within the protocol? For example,
the framing protocol (referring only to the encapsulation of direction,
version, flags, opcode, length, and message body) currently has version 1, but
maybe the rest of the protocol (the exact format and set of the supported
messages) could have something fitting the Semantic Versioning stuff. This
would let the client know whether a difference in the server-side protocol
version(s) was/were compatible with the client's own supported version(s) or
not. Maybe we could even negotiate a protocol version between the server and
client with the OPTIONS/STARTUP pair.
If we don't do this, and we end up making 127 changes to any part of the
protocol over time (definitely possible), then we have no backward-compatible
way to state a higher version number.
> 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
> Fix For: 1.2
>
> 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
