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_cassan...@core43.com> 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-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
