dumping libzip

[Dirk Hohndel]

On Wed, 2014-01-08 at 00:44 +0200, Lubomir I. Ivanov wrote:
> > It's a bit early still for us here in Australia... but my reaction is
> > this:
> >
> > a) I don't want to add a dependency to a library that is hard to get for
> > people.
> >
> 
> i guess, that's the whole point of including a library snapshot in our source.
> it will improve over libzip, which does not have support for reading
> buffers and is broken on win32 paths.

Understood - that's why we are talking :-)

> > b) If we add minzip to our sources (which based on the license we can)
> > we de-couple ourselves from its upstream. But that may be acceptable.
> >
> 
> i think it can fit much better.
> i see a lot of c++ projects that do that and wrap the minizip around
> c++ code and handle zip archives locally not depending on libraries
> like libzip.
> libzip has requests for buffer i/o made early 2012, and the response
> is "Unfortunately, no", which i don't think is serious for such
> project.
> 
> > c) I don't want to carry around code that isn't used - so what's the
> > delta of functionality that it offers versus the functionality that we
> > actually need? Or said differently, are there parts that we could easily
> > remove while maintaining the functionality that we need? In order to
> > make the library smaller and easier to maintain?
> >
> 
> i think we can.
> there is just some basic source code in the lines of "io functions
> like fopen", "zipping stuff", "unzipping stuff" and some helper
> headers.
> we need to include those .o files in our files and simply use the zlib
> shared library.

Why a shared library? Why not just link them into our executable?

> the i/o buffer support from minizip is not part of zlib upstream and
> it seems to be only in the minizip upstream.
> we technically need that in locations like subsurfacewebservices.cpp
> and file.c, but we can still manage to open files instead of buffers.

I assumed based on your last set of emails we were planning to use the
minizip upstream as starting point.

> > d) alternatively, would it make sense to use it ONLY under Windows (so
> > that way I can deal with building it locally and create binaries and the
> > rest of the OSs can happily keep using their existing libzip)?
> >
> 
> i'm not sure - too much abstraction IMHO in the case of using one lib
> on one OS and one on the other, but it's doable.
> i'd much rather favorite a portable self contained, local library that
> has a good API and that can be used everywhere with zlib.

OK, spell this out for me some more - what exactly do you mean by "can
be used everywhere with zlib"? I just want to make sure there's no
misunderstanding here...

> p.s. as i side note (and from the C point of view) the minzip stuff is
> a little bit more low-level in comparison to libzip.
> i've tested that to some extend, but seeing many projects use it i
> don't see a problem.

Again, can you say a little more about that?

Thanks

/D