On Fri, May 17, 2024 at 3:15 AM Robert Haas <robertmh...@gmail.com> wrote: > > OK, so you made it so that compressed data is fully self-identifying. > Hence, there's no need to worry if something gets changed: the > receiver, if properly implemented, can't help but notice. The only > downside that I can see to this design is that you only have one byte > to identify the compression algorithm, but that doesn't actually seem > like a real problem at all, because I expect the number of supported > compression algorithms to grow very slowly. I think it would take > centuries, possibly millenia, before we started to get short of > identifiers. So, cool. > > But, in your system, how does the client ask the server to switch to a > different compression algorithm, or to restart the compression stream?
I was leaving the details around triggering that for this conversation and in that patch just designing the messages in a way that would allow adding the reconfiguration/restarting to be easily added in a backwards-compatible way in a future patch. I would imagine that an explicit `ParameterSet` call that sets `_pq_.connection_compression` (or whatever the implementation details turn out to be) would also trigger a compressor restart, and when restarted it would pick an algorithm/configuration based on the new value of the parameter rather than the one used at connection establishment. -- Jacob Burroughs | Staff Software Engineer E: jburrou...@instructure.com