[
https://issues.apache.org/jira/browse/CASSANDRA-2478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13407963#comment-13407963
]
Sylvain Lebresne commented on CASSANDRA-2478:
---------------------------------------------
bq. This draft spec doesn't allow much in that respect.
:(
That's was certainely not the intention so let me try to give my point of view.
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.
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.
But let me be clear that I don't pretend the current committed version to be
perfect or in any way final. I wanted it committed so that people can try
working with it and give feedback. I typically don't think we should call the
first version of the protocol final before there is at least 2 or 3 drivers (in
different language) that uses it.
But once we get to that first final version, I think that at the very least we
should not bump the protocol version between minor C* version. And truth is,
while I expect burning a few versions towards the beginning because I'm sure we
won't get everything right, if we continue burning 1 version of the protocol
every major C* version after say version 3 or 4 of the protocol, then I would
consider that a big big failure on our part (if only because no driver
implementor in its right mind will want to put up with our shit if we do that).
But even if that happens, with one major C* release every 6 months, we're good
for some time.
Besides, if I happen to be completely off the mark and we do burn version like
crazy, version 127 of the protocol can very well add a new byte to the header
to increase the number of possible versions. But I estimate the chances of that
happening to be 0.
That being said, and to make things a bit more flexible, I did put a paragraph
to the spec saying that clients should never expect a message to contain no
more data that what they know about. So it will be possible to add optional
info in the server response without having to burn a protocol version, which
might be handy.
Also, the OPTIONS/STARTUP pair is here exactly so that there can be some
negotiation, which will allow to support new optional features without
necessarily increasing the protocol version, reducing a bit more the change
that do need to increment the protocol version.
Overall, I did though about that compatibility issue quite a bit and I do think
the protocol is not too ill equipped already to deal with that. In any case, it
will always be possible to extend the versioning later if we really need to,
but I do want to believe that we'll be able to have a fairly stable protocol
(with optional features negotiated at startup), and I prefer not designing the
first version of the protocol assuming we will fail at 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
> 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
