Hi Bastian,
Thank you for the tip to have a look at libarchive.
I see the advantage that libarchive would give us over straight zlib with
regard to additional compression formats and the ability to read tar and zip
archives without including community contrib files to zlib as we do now for
this. My fear is that we would be depending on more than the ubiquitous zlib.
Not only would we need to be sure libarchive was installed and available for
Android and iOS, macOS, Linux, etc., when zlib is usually already present, but
it looks like libarchive itself has its own list of dependencies we would need
to add for all of our users. I am mostly concerned with our smaller platforms
like Android, iOS. It's already a pain to build for these platforms, as it is.
I would love for you to jump in and contribute, but we are often led to take a
bit of a longer and less sexy path sometimes to assure minimal dependencies to
help us run as widely as possible. I hope that's makes sense. If this zlib zip
archive expand contrib code doesn't work out to be as cross platform as its
contrib untar counterpart has proven to be, we can certainly keep libarchive in
mind. I'm also happy to hear more thoughts.
What part of Germany are you in? I'm working in Göttingen and Münster this
summer.
Troy
On June 1, 2022 6:21:12 PM GMT+02:00, Bastian Germann
<bastiangerm...@fishpost.de> wrote:
>Hi Troy,
>
>Am 30.05.22 um 01:36 schrieb Troy A. Griffitts:
>> 1) new unzip expansion support in the engine:
>>
>> we've wanted, for a while now, to support zip archive expansion;
>> historically, we've supported tar.gz expansion. My issue in the past is
>> that zlib only supports the decompression action, not actually reading an
>> archive of files and expanding them. zlib does include a contrib/ folder
>> which has enough functionality to provide this. I've finally waded through
>> it all and it appears it might be cross-platform enough for us to compile on
>> our targets. The new files are:
>>
>> src/modules/common/ioapi.c
>> src/modules/common/unzip.c
>> include/internal/unzip/ioapi.h
>> include/internal/unzip/unzip.h
>>
>> with a new static method on our class ZipCompress::unZip(const char
>> *sourceZipPath, const char *destPath);
>
>Have you had a look at libarchive? I think, introducing this can get rid of a
>lot of the compression source files and would simplify the codebase. It is a
>mature library; even Microsoft uses it on Windows 10/11 to provide tar.
>I have used it with https://gitlab.com/bgermann/unrar-free and really liked
>the documentation.
>
>All the SWORD-supported compression types should be supported in libarchive
>except for LZSS, which is only part of the RAR implementation. However, there
>might be a chance to refactor and make it a primary compression filter. If you
>like the idea of libarchive in SWORD I am willing to have a try at the
>libarchive code base.
>
>Thanks,
>Bastian
>_______________________________________________
>sword-devel mailing list: sword-devel@crosswire.org
>http://crosswire.org/mailman/listinfo/sword-devel
>Instructions to unsubscribe/change your settings at above page
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
_______________________________________________
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
