Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support custom dictionaries #27

Open
ricea opened this issue Feb 6, 2020 · 3 comments
Open

Support custom dictionaries #27

ricea opened this issue Feb 6, 2020 · 3 comments
Labels
addition/proposal New features or enhancements needs concrete proposal Moving the issue forward requires someone to figure out a detailed plan

Comments

@ricea
Copy link
Collaborator

ricea commented Feb 6, 2020

The "deflate" format supports preset dictionaries. These permit backreferences to be used from the start of the data to refer to items in the dictionary as if it was prepended to the uncompressed data. This can give significant improvements in compression ratio, particularly for small inputs. See FDICT in RFC1950. This is also a common feature in other compression formats.

This should be supported by CompressionStream and DecompressionStream.

For CompressionStream, an obvious API would be

const cs = new CompressionStream("deflate", { dictionary: aBufferSourceObject });

An open question is whether it is necessary to be able to pass multiple dictionaries to DecompressionStream (keyed by the Adler32 checksum), or whether just passing a single dictionary is sufficient. If we only support passing a single dictionary, this requires the calling code to either know by some out-of-band method what dictionary is in use, or parse the Adler32 checksum out of the header itself to choose the right dictionary.

@mormahr
Copy link

mormahr commented Oct 22, 2020

API responses with a fixed schema would be an obvious use case here. For example, one could generate a dictionary from a GraphQL schema and even weighted by the number of requests per field key.

@ricea
Copy link
Collaborator Author

ricea commented Oct 22, 2020

@mormahr How do you feel about { dictionary: aBufferSourceObject } vs. { dictionaries: { 0x12345678: aBufferSourceObject } }

We could of course support both, but that would be ugly.

@mormahr
Copy link

mormahr commented Oct 22, 2020

I have no idea how all of that works. Since there isn't anything available in the browser (yet), I haven't looked further into my idea, so I don't really know what the proper API design is.

@annevk annevk added addition/proposal New features or enhancements needs concrete proposal Moving the issue forward requires someone to figure out a detailed plan and removed enhancement labels Oct 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
addition/proposal New features or enhancements needs concrete proposal Moving the issue forward requires someone to figure out a detailed plan
Development

No branches or pull requests

3 participants