On-demand flush

[mfulton26]

I have a suspicion that using text/event-stream with CompressiomStream could cause delays in delivering events to consumers but I'm not sure that's true or not. It seems to me that after enqueing some event(s)/chunk(s) that the compression stream could be in a waiting state for more bytes to compress before it enques corresponding compressed chunk(s).

Is some flush() method needed in order to reliably send a compressed stream of events and to guarantee that individual events are not delayed?

Demo: https://dash.deno.com/playground/event-stream-example

[ricea]

Yes. See also #22.

[mfulton26]

Is there an expected flushing strategy for browsers to implement today for CompressionStream or is it undefined? If it is already "always" then I'm set for my current use cases but I'm guessing that is not the case. I wonder if there is an expected flushing strategy with which I might be able to find a workaround. Thank you.

[ricea]

Sorry, it is implementation-dependant at the moment. I don't think there's a good workaround. We should make it a priority to fix #22 once the migration from WICG to WHATWG is done.