The solution to all these problems is XPK.
The XPK standard is to data compression what xpr is to file transmission. It consists of three layers:
In addition, there is an optional standard XPK file format.
All parts of the XPK standard are implemented in shared libraries. There is one master library for archive level access, one master library for file level access, and one library for each compression algorithm.
level 2 libxpkarchive | | V | level 1 libxpkmaster | | | | V level 0 type 3 | | | xarZOO | | V type 2 | | xexXPWP V V type 1 xpkNUKE xpkENCO
All level 0 libraries offer the same functions. They are very small. Typical calls are: "Tell me what you can", "Compress this chunk of memory to another chunk of memory", and "Decompress this chunk of memory to another chunk of memory". These libs are very limited, their functionality is expanded by libxpkmaster. No one would want to talk to a sub library directly.
Offers functions like "Compress this file to that chunk of memory using that algorithm". All combinations permitted: Mem to mem, file to file, mem to file, decompression and compression. Asynchronous packing possible. Very convenient tag based caller interface. Determines automatically out which sub library to use for decompression. Returns detailed error messages.
Offers archiving functions like "add this file to that archive" or "show me the contents of that archive".
It is planned, that libraries of a lower level can offer higher level functions. They should be able to override the automatic functionality expansion by the higher level library. xpkmaster.library, for example, enforces the use of the XPK standard file format. It should be possible to override this by a sub library. Therefore an new library interface will be created, the xex libraries.
Offers checksums, chunks (important when seeks on a compressed file become necessary) and automatic handling by the libxpkmaster. This means that any new packer that can only pack mem to mem has its own file format immediately. And most important: The name of the packer library is contained in the file. Therefore, copying a new sub library to libpath is all you have to do to install a new packer (easily done in installation scripts); libxpkmaster recognizes the new file type immediately. No changes to libxpkmaster or the application programs necessary. In case the XPK file format is not used, the introduction of a new packer requires a change the libxpkmaster.
A few examples for applications that could use XPK:
...plus many more we do not even need to think about yet.
XPK would increase the usefulness and flexibility of both application and compression programs while improving their user friendliness at the same time. The best way to establish this standard would be to distribute it with every UNIX distribution :).