OSDir

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Evolving the client protocol


The protocol does already support optional/custom payloads to do such things.  IIRC the zipkin tracing implementation https://github.com/thelastpickle/cassandra-zipkin-tracing for example uses this to pass the zipkin id to the server.

> On Apr 20, 2018, at 1:02 PM, Max C. <mc_cassandra@xxxxxxxxxx> wrote:
> 
> For things like #3, would it be a better idea to propose a generic enhancement for “optional vendor extensions” to the protocol?  These extensions would be negotiated during connection formation and then the driver could (optionally) implement these additional features.  These extensions would be documented separately by the vendor, and the driver’s default behavior would be to ignore any extensions it doesn’t understand.
> 
> With that sort of feature, the Scylla folks (CosmoDB too??) could add extensions to the protocol without forking the protocol spec, (potentially) without forking the drivers, and without laying down a C* roadmap that the C* project hasn’t agreed to.  Someday down the line, if C* implements a given capability, then the corresponding “vendor extension” could be incorporated into the main protocol spec… or not.
> 
> Lots and lots of protocols implement this type of technique — SMTP, IMAP, PNG, Sieve, DHCP, etc.   Maybe this a better way to go?
> 
> - Max
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxxxx
> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxxxx
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxxxx
For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxxxx