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
