dumping libzip

[Lubomir I. Ivanov]

On 8 January 2014 00:49, Dirk Hohndel <dirk at hohndel.org> wrote:
> 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.
>

we can, but i was concerned about our code base inflation based on
previous emails in this thread.
the minizip upstead adds some extra 1k-2k lines of code just for that
buffer i/o API.

if we use zlib upsteam minizip does not have support for buffer i/o.

>> > 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...
>

zlib is a core ZIP format library that even runs on Amiga.
libzip and minizip are filesystem and file management libraries that
handle file inclusion and extraction in/from ZIP.

we pretty much need a portable library that works with zlib.

>> 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


not that difficult to maintain compared to libzip.
it's just the standard:

my_struct *zip = open_my_zip_file(...)
if (zip) {
    puts("ok good to go");
}

but slightly more verbose at it has better, but lower level API than libzip.
i can ensure that if i'm about to send patches for that to test
everything beforehand.
( and where schedule permits to do so :(   )

lubomir
--