Request for Features/Ideas: A std.archive package

[Dejan Lekic via Digitalmars-d]

On Sunday, 17 May 2015 at 16:32:31 UTC, Liam McSherry wrote:
> Phobos currently has packages for working with various archives 
> (Zlib/Gzip, Zip), and it's probably reasonable to expect that 
> support for more archive formats will be added in future. 
> Before any more are added, it would probably be beneficial to 
> define an interface that any modules adding support for 
> archives should obey, and having archive related modules under 
> std.archive for organisational purposes probably wouldn't hurt.
>
> I saw a suggestion for improved archive support on the D wiki's 
> wish list, and the code link 'std.archive' module in the review 
> queue now 404s, so it looks to be the case that there isn't 
> currently an effort to implement an archiving package for 
> Phobos. What I would propose for such a package is:
>
> - Split archives in to two categories: stream-based (Gzip, 
> Zlib, Bzip, etc) and file-based (Zip, Tar).
> - Make support for creating archives optional (e.g. by having 
> IStreamArchive and IWritableStreamArchive).
> - Make compression-related functionality separate (e.g. through 
> an ICompressableArchive(T) interface, where T is an enum 
> specifying algorithms). I'm not sure on this one, so ideas are 
> especially welcome for it.
> - A hierarchy of exceptions for implementations under 
> std.archive rather than the current Phobos norm of everything 
> having its own exceptions.
>
> I'd like to know whether there would be demand for such a 
> package, and what the community would want in terms of the API 
> and features. I haven't yet written any code for the package as 
> the API is going to be one of the most important parts, and I 
> thought it would be best to have agreement on what is wanted 
> before starting on it.

We need two things actually:
1) compress package with set of commonly used compression 
algorithms.
    std.alg.compress comes to mind as package name.
2) VFS module/package with set of interfaces and reference 
implementations for as many formats as possible.
3) It would be extremely useful to have something like Java SPI 
(http://en.wikipedia.org/wiki/Service_provider_interface) in D. 
All the VFS implementations would then follow this standard and 
give us truly runtime-replaceable components. More about this: 
http://resources.sei.cmu.edu/asset_files/TechnicalNote/2002_004_001_13958.pdf