Legacy Brotli

[dmitrylyzo]

1. A bunch of polyfills need to be added to support Brotli compression in legacy browsers.
   Some of them (marked From brotli) are from https://github.com/google/brotli/blob/master/js/polyfill.js So they can be added by this file passed in emcc.
   At the same time, if something changes in Brotli polyfills, it may affect JSO. For example, there is no Int8Array.slice in the version currently used by JSO, but there is in the latest recent.
   Therefore, it is probably better to rely on Emscripten polyfills and explicitly added JSO polyfills.

2. URLs can contain params. For example, in Jellyfin the URL looks like /Videos/{1}/{2]/Subtitles/{3}/{4}/Stream.ass?api_key={5}.
   Jellyfin doesn't support Brotli compressed subtitles yet, but maybe someday.
   If you want, I can extract this part in a separate PR.

Tested in webOS 1.2 emulator with Brotli subtitles from gh-pages branch.

Some thoughts
Maybe extract polyfills in polyfills.js and add them only to the legacy worker?

[TheOneric]

Maybe extract polyfills in polyfills.js and add them only to the legacy worker?

Seems sensible, though if JSO switches to emscripten's combined WASM=2 mode in the future it will need to be added to both again.

Some of them (marked From brotli) are from https://github.com/google/brotli/blob/master/js/polyfill.js
[...] it is probably better to rely on Emscripten polyfills and explicitly added JSO polyfills.

I agree that having the polyfills provided by Emscripten would be ideal, but failing that utilisng brotli's polyfill.js seems better imho, as it should in theory automatically add polyfills only required for brotli whenever we update brotli — otherwise we would need to update this manually. If you're worried about brotli's polyfills not being general enough, loading our own polyfills before brotli's polyfill.js will result in our versions being used, right?

For example, there is no Int8Array.slice in the version currently used by JSO, but there is in the latest recent.

Grepping for \.slice yielded no match in the currently used version of brotli's decode.js, so I guess this version of brotli doesn't yet need it. If it's already required we could also bump the brotli dependency beyond the current release.

[dmitrylyzo]

If you're worried about brotli's polyfills not being general enough, loading our own polyfills before brotli's polyfill.js will result in our versions being used, right?

I'm mostly concerned about polyfill duplication. No harm, but it will bloat the output file.

Grepping for .slice yielded no match in the currently used version of brotli's decode.js, so I guess this version of brotli doesn't yet need it. If it's already required we could also bump the brotli dependency beyond the current release.

It seems that slice is used by Emscripten: the buffer.slice(offset,offset+length) call in MEMFS.
Above, I meant that what if brotli suddenly stops using slice and removes the slice polyfill, it needs to be added back to cover Emscripten's needs.

Btw, in webOS 1.2 from polyfill adds from to each Object, because Int32Array.__proto__ === {}.__proto__: true. It works, but seems wrong to me.

[TheOneric]

Above, I meant that what if brotli suddenly stops using slice and removes the slice polyfill, it needs to be added back to cover Emscripten's needs.

If it's used by emscripten not just brotli, than it would be defined in our own polyfills, which should take precedence over brotli's polyfills, and since it wouldn't be removed (until emscripten starts to provide the polyfills).
The intended benefit of including brotli polyfills lies in it automatically covering all needed polyfills for brotli, without anyone needing to test specifically old engines eacht ime we bump it. But ofc, there's also the possibilty that changes to JSO code or bumping emscripten might lead to new polyfills being required (and we don't test for that); perhaps this means not including brotli's own polyfills doesn't make much of a difference. Is the “bloat” and adding “from to each Object” problematic?

On another note, just copying polyfills from lib/brotli/js/polyfills.js to src/… can in gneral have licence/copyright-implications. By chance JSO and brotli use the same Expat-style "MIT"-licence, but we'd also need to copy the original copyright notice — but brotli's polyfill.js doesn't have one, so I'm not sure if we're supposed to fallback to the default attribtuion from brotli's LICENCE or just not do anything. Ofc, trivial code which the current ones maybe count as isn't copyrightable in the first place.