> On 26 Mar 2018, at 18:19, Vladimir Sitnikov <sitnikov.vladi...@gmail.com> > wrote: > > Tom>But starting from the assumption that HTTP2 solves our problems seems to > me to be "Here's a hammer. > > Agree.
Funny you agree with that—for someone having the experience of writing a driver and having a long list of things that you find wrong and frustrating, one would expect you do look at how other protocols work, or at least consider that maybe the right way is to change something server side. > > Just a side note: if v4 is ever invented I wish client language support > is considered. > It does take resources to implement message framing, and data parsing (e.g. > int, timestamp, struct, array, ...) for each language independently. This is a strange statement about framing. Did you know that Go has HTTP2 support in the standard library? And so does java, too? https://github.com/http2/http2-spec/wiki/Implementations <https://github.com/http2/http2-spec/wiki/Implementations> The part I hinted at in the example but did not get the message across is that I’m advocating the best possible client language support. The right way is to stop writing drivers and format the data server side. Why parse some obscure Postgres-specific binary data types when you can have the database send you the data in the serialization format of your client language? Or JSON or protobuf or whatever you want. What if your application has data patterns that would benefit from being sent over the wire in some specific columnar format? Wouldn’t it be cool if you could add that to the server and have all clients just work, without being locked in into a language because of its driver? My point is that you go in steps. Put the foot in the door first, enable experimentation and then you’ll get to where you want to be. > > Vladimir
