Что такое хорошие ориентированные на сжатие интерфейсы прикладного программирования (API)?

Question

Что такое хорошие ориентированные на сжатие интерфейсы прикладного программирования (API)?

Люди все еще используют 1991 "стандарт сжатия данных" проект стандарта, и 1991 «Интерфейс алгоритма преобразования потока», проект стандарта. (Оба проекта стандартов Росса Уильямса )? Есть ли альтернативы этим проектам стандартов?

(Я особенно ищу API-интерфейсы C, но ссылки на API-интерфейсы, ориентированные на сжатие в C ++ и других языках также приветствуются).

Я экспериментирую с некоторыми алгоритмами сжатия данных. Обычно сжатый файл, который я создаю, состоит из серии блоков, с заголовком блока, указывающим, какой алгоритм сжатия необходимо использовать для распаковки оставшихся в этом блоке данных - Хаффмана, LZW, LZP, «сохраненные несжатые» и т. д.

Заголовок блока также указывает, какие фильтры необходимо использовать для преобразования промежуточного потока или буфера данных из декомпрессора в копию исходного текста без потерь - преобразование Берроуза-Уилера, дельта-кодирование, окончание XML. восстановление тегов, «копирование без изменений» и т. д.

Вместо использования огромного оператора switch, который выбирает на основе «типа сжатия», который вызывает выбранный алгоритм декомпрессии или алгоритм фильтрации, каждая процедура со своим собственным специальным номером и порядком параметров, это упрощает мой код, если каждый алгоритм имеет одинаковый API - одинаковое количество и порядок параметров и т. д.

Вместо того, чтобы ждать, пока декомпрессор пройдет через весь входной поток, прежде чем передать его вывод первому фильтру, Было бы неплохо, если бы API поддерживал распакованные выходные данные, выходящие из окончательного фильтра «относительно быстро» (с малой задержкой) после того, как относительно небольшие сжатые данные были поданы в начальный декомпрессор. Было бы хорошо, если бы API можно было использовать в системах, которые имеют только один поток или процесс.

В настоящее время я собираю свой собственный внутренний API, повторное использование существующих реализаций алгоритма сжатия написание коротких функций-оболочек для преобразования между моим внутренним API и специальным числом и порядком параметров, используемых каждой реализацией.

Есть ли уже существующий API, который я мог бы использовать вместо того, чтобы создавать свой собственный с нуля? Где я могу найти такой API?

Answer 1

Боюсь, такого «API» не существует.В частности, такое требование, как «начало этапа-2, когда этап-1 продолжается и еще не завершен», полностью зависит от реализации;и не может быть добавлен позже уровнем API.

Кстати, Maciej Adamczyk только что попробовал то же самое, что и вы.Он сделал бенчмарк с открытым исходным кодом, сравнивая множественные алгоритмы сжатия со сценарием блочного сжатия.С кодом можно ознакомиться здесь: http://encode.ru/threads/1371-Filesystem-benchmark?p=26630&viewfull=1#post26630

Он был вынужден "заключить в капсулу" все эти различные интерфейсы компрессора, чтобы справиться с разницей.Теперь хорошо: большинство компрессоров имеют тенденцию иметь относительно схожий интерфейс C , когда дело доходит до сжатия блока данных .Как пример, они могут быть такими же простыми, как этот: http://code.google.com/p/lz4/source/browse/trunk/lz4.h Так что, в конце концов, уровень адаптации не такой тяжелый.