--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMp5r%2BzN2xkbJ%2B-_-0-L%2BNN17DUU6gZJkwwkMkQdsnSG2weNgg%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABc02_%2BWkEvu9k7LmjEaFUjnWF4cGX38rnDwZ4_n5dmnsEzWCg%40mail.gmail.com.
With regard to the Beacon use case, is the async nature of the API compatible with the new/upcoming restrictions on what sorts of code can run in beforeunload handlers?
With regard to the Beacon use case, is the async nature of the API compatible with the new/upcoming restrictions on what sorts of code can run in beforeunload handlers?
I'm excited to see this as well, and I'm glad to see that there's a corresponding DecompressStream. One immediate thought is that this would be a useful primitive for building JavaScript apps that manipulate files in the popular ZIP format (based on DEFLATE). I'd be very excited if brotli encoders and decoders were available, given the size/performance of polyfilling.
With regard to the Beacon use case, is the async nature of the API compatible with the new/upcoming restrictions on what sorts of code can run in beforeunload handlers?
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/de342790-a637-4208-b038-0886f4e69b6e%40chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABc02_%2BWkEvu9k7LmjEaFUjnWF4cGX38rnDwZ4_n5dmnsEzWCg%40mail.gmail.com.
That actually means that it is supported at the protocol level. Pre-advertising the feature is not supported.
(Middleboxes are broken in many other aspects anyway and are not part of the protocol)
What if individual fields are compressed rather than the entire payload (less efficient sometimes, but still may have some benefit)? Would this also incompatible with middleboxes? Or simply very inefficient?
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/81531c85-b64d-450a-99fb-bd13ff71d717%40chromium.org.
Can you list significant use cases for this feature other than uploading and local storage? I am struggling to find a real use case that should not be built in.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABc02_JRdAe0L8sFArXp3UGMTNnzoeYvEQCcg%3DSp9vAdtiEt_g%40mail.gmail.com.