[
https://issues.apache.org/jira/browse/CASSANDRA-2478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13408275#comment-13408275
]
paul cannon commented on CASSANDRA-2478:
----------------------------------------
bq. First, I think that for dealing with cross-version compatibility, having
one single version number is much easier than splitting it in 2 different
versions. All you care about is 'can I have a discussion with that server', and
there is no point in adding complexity by having to check 2 numbers (this would
also complicate documentation typically), so I'm fairly strongly against that
idea.
It doesn't need to add much complexity; it's just a separation of layers, both
of which would be more simple afterward. Any good implementation of this
protocol will already be handling the framing at a different level than the
messaging. But if you're that much against it, that's fine, I'd be ok with just
a single, wider version space.
bq. Now there is the question of whether we'll have enough version number with
the current format. First, I certainly hope so. I think that the protocol
should be something as stable as we possibly can, and I honestly don't think
things in the protocol will change all the time. There is really so many thing
that a protocol can do and so many things we can add.
I wholeheartedly agree we want the protocol to be as stable as possible, while
still evolving toward additional needs (I'm very much with the other commenters
suggesting that async messaging will be important soon, and also
challenge/response auth). I also hope that we won't need more than a few dozen
revisions total. But I find it unlikely; the very nature of network protocols
is that the more specific in intention they are, the more they will need to
grow over time.
Another consideration is letting servers and clients know, if their protocol
versions differ, whether they're still compatible with each other. This is
vital information to have—it *will* be necessary in practical situations for
clients to speak with multiple server versions and for servers to speak with
multiple client versions. Think rolling upgrades or multiple client libs in use
simultaneously.
Finally, what's the rationale for *not* having a three-part semantic version
for the protocol? It's an extra *two bytes* used per connection. There's
practically no downside, and a massive potential upside.
bq. I prefer not designing the first version of the protocol assuming we will
fail at that.
It's not an assumption that we will fail; it's (a) a signal to clients of
compatibility and (b) an acknowledgement of a possibly-remote chance of
failure; a safety net. It's just like having exception handlers around complex
code, even if you don't expect to need them. It's just good design.
> 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
