Итак, в стандартном KLE есть текущая клавиатура, которую мы редактируем. С точки зрения языка программирования она является объектом. Как и любой обычный объект в JS, его можно представить в виде JSON, и так хранить.
Но автор KLE решил так не делать, и он придумал сложнющий формат "сериализации", в котором он хитро обрабатывает клавиши в одном ряду, чтобы на этом экономить место. Что порождает баги. Как я понял, единственное предназначение этого сложнющего формата - это чтобы результат был сжат, и на gist хранился в максимально компактном формате.
Я же отказался от этого формата, и храню клавиатуру абсолютно напрямую, из-за чего возникают несовместимости между нашей KLE, и оригинальной.
Так вот, я как-то высказал идею что вместо изобретения такого сложного формата можно сделать следующее: тупо взять json клавиатуры, минимизировать его, убрав лишние пробелы, затем сжать zip'ом, а затем это записать в base64 и так выкладывать на gist.
И я сегодня провёл эксперименты:
-
Мой самый сложный слой, где нарисованы всякие аккорды, в несжатом виде занимает 137.1кб.
-
После минимизации, сжатия и преобразования в base64 он стал занимать 7.1кб, что вполне удовлетворительно.
-
Оригинальный алгоритм KLE выдаёт json'ку размером 10.8кб.
-
После сжатия верхнего пункта получаем 2.1кб.
Я сжимал таким кодом:
cat $1 | jq -c . | gzip -9 -c - | base64 > minified_zip.base64Видно, что тупой подход + тупое сжатие = размер меньше, чем сложный алгоритм автора. Но если использовать сложный алгоритм автора и сжатие, то получаются чудеса.
Я считаю, что эти чудеса того не стоят, потому что его формат получился слишком сложным, и в нём имеются баги, которые автор никак не может пофиксить уже 2 года.
Из чего мы делаем вывод: если когда-то по какой-то причине тебе захочется какие-то json-ки хранить на gist, то лучше это делать через zip+base64, чем изобретать свой формат. Json'ки все понимают и все их в своих языках смогу обработать.