什么是良好的面向压缩的应用程序编程接口（API）？
人们还在使用 1991年“数据压缩接口”草案标准，和 1991年“流转换算法接口”草案标准。 （draft standards by Ross Williams）？ 这些标准草案有其他替代方案吗？
（我特别关注C API，但也欢迎使用C ++和其他语言链接到面向压缩的API。）
我正在尝试一些数据压缩算法。 通常，我正在生成的压缩文件由一系列块组成， 带有一个块头，指示需要使用哪种压缩算法来解压缩该块中的剩余数据 - Huffman，LZW，LZP，“存储未压缩”等等。
块头还指示需要使用哪个过滤器将来自解压缩器的数据的中间流或缓冲区转换为原始明文的无损副本--Burrows-Wheeler变换，delta编码，XML end-标签恢复，“复制不变”等。
而不是使用基于“压缩类型”选择的巨大switch语句，它调用所选的解压缩算法或过滤算法，每个过程都有自己的特殊数量和参数顺序， 如果每个算法都具有完全相同的API - 相同数量和参数顺序等，它简化了我的代码。
在将输出交给第一个过滤器之前，不是等待解压缩器运行整个输入流， 如果在将相对较少的压缩数据馈送到初始解压缩器之后，API支持解压缩输出数据“相对快速地”（低延迟）从最终过滤器出来，那将是很好的。 如果API可以在只有一个线程或进程的系统中使用，那就太好了。
目前我正在将我自己的内部API整合在一起， 重用现有的压缩算法实现 编写短包装函数以在我的内部API和每个实现使用的特殊数字和参数顺序之间进行转换。
我是否可以使用已经存在的API而不是从头开始设计自己的API？ 我在哪里可以找到这样的API？
答案 0 :(得分：3)
我担心这样的“API”不存在。 特别是，诸如“第一阶段，第一阶段正在进行和未完成”的要求完全取决于实施;并且以后不能通过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 所以，最后，适应层不是那么重。