Extensions API doesn't allow for selective compression

[glasser]

The permessage-deflate spec is designed to allow senders to choose not to compress all messages (eg, messages that already contain compressed binary data), but the extensions API doesn't allow senders to make this choice.

(My personal needs don't require this, but it does seems like something that users might care about.)

[jcoglan]

I'm parking this for the moment since I have no idea what an API should look like. No API for this exists in the browser (as far as I know), although some browsers (Opera) do skip compression on small messages where compression would actually enlarge the payload. I'm not sure how they do that; you can't compress a message and then compare the size, because that alters the state of the DEFLATE context and you must transmit the compressed payload to the other peer so it can mirror those changes.

My main concern is about surfacing extension control parameters via send() without coupling anything from websocket-extensions upwards to the extensions. My article this week sheds light on how I designed this stack, and which kinds of couplings I don't want to introduce.

[jcoglan]

I'm also not sure conceptually what should be parameterised per send() call. e.g. if a peer is using context takeover, can you tell it to start a new context on a particular message? Is that safe? Can you change the window size, or level, or strategy, per message?