On Mon, 2008-08-25 at 23:22 -0700, John MacFarlane wrote:

I've written a library, zip-archive, for dealing with zip archives.

Great. I saw your query about this from a month ago.

Haddock documentation (with links to source code): http://johnmacfarlane.net/zip-archive/

Darcs repository: http://johnmacfarlane.net/repos/zip-archive/

It comes with an example program that duplicates some of the functionality of 'zip' (configure with '-fexecutable' to build it).

I intend to put it on HackageDB, but I thought I'd get some feedback first. Bug reports, patches, and suggestions on the API are all welcome.

Generally it looks good, that the operations on the archive are mostly separated from IO of writing out archives or creating entries from disk files etc. Looking at the API there feels to be slightly too much exposed. Eg does the MSDOSDateTime need to be exposed, or the (de)compressData functions. I've been reworking the tar library recently and currently have an api that looks like: -- * Reading and writing the tar format read :: ByteString -> Entries write :: [Entry] -> ByteString -- * Packing and unpacking files to\/from a tar archive pack :: FilePath -> FilePath -> IO [Entry] unpack :: FilePath -> Entries -> IO () Entry is like your ZipEntry. Entries is a little special. Tar is really a linear/streamable format, we typically read the file front to back. Of course with zip it's more complex as you have an index (right?) and you can jump around without reading all the data. So Entries represents the unfolding of a tar file as a sequence of entries, but with the possibility of failure (eg format decoding failures): -- | A tar archive is a sequence of entries. data Entries = Next Entry Entries | Done | Fail String So that's why we have Entries for the result of decoding and just an ordinary list for the input to encoding. Zip is more complex of course because you often want to add files to existing archives, or lookup individual entries without just iterating through each entry. My personal inclination is to leave off the Zip prefix in the names and use qualified imports. I'd also leave out trivial compositions like readZipArchive f = toZipArchive <$> B.readFile f writeZipArchive f = B.writeFile f . fromZipArchive but reasonable people disagree. For both the pack in my tar lib and your addFilesToZipArchive, there's a getDirectoryContentsRecursive function asking to get out. This function seems to come up often. Ideally pack/unpack and addFilesToZipArchive/extractFilesFromZipArchive would just be mapM_ extract or create for an individual entry over the contents of the archive or the result of a recursive traversal. So yeah, I feel these operations ought to be simpler compositions of other things, in your lib and mine, since this bit is often the part where different use cases need slight variations, eg in how they write files, or deal with os-specific permissions/security stuff. So if these are compositions of simpler stuff it should be easier to add in extra stuff or replace bits. Duncan