> On Thu, Nov 04, 2021 at 10:26:20AM +0000, Zbigniew Jędrzejewski-Szmek wrote: > > But a binary representation of that could strip it down into ~50%. Would it though? Have you tested and checked it to make that determination? Can you share the code to reproduce it? The values necessarily have to be strings, since the data varies unpredictably. The longest data fields are most likely going to be CPE and debuginfod URLs, package name and package version, which can be in the worst cases a few dozen bytes each. And to avoid completely throwing extensibility and flexibility to the wind, which is one of the key aspects of the proposals, the keys have to be strings too, so that each producer can add new fields if they want to, and users/support/maintainers can read them just fine without knowing all possible keys in advance. So at most you'd save from the json's quotes, commas and colons - that's 6 bytes per field. With 5 fields, that's 30 bytes saved without considering the space needed for the header encoding sizes and whatnot, on a total of ~200 bytes, with a considerable worse usability (custom format needing its own parsers and builders instead of well-known and understood json). It doesn't seem worth the trouble. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
