Closed herzi closed 1 year ago
Hi,
unfortunately, no one. Because the purpose of InStream
is proving raw archive's file data buffer(from file, mem buff., network, etc.). It's not a compressed stream and this SDK is oriented on processing archives.
For your needs(compressed streams), this SDK is preaty heavy, and you need only small C part of it.
In case if your project conforms next versions: iOS 13.0+ iPadOS 13.0+ macOS 10.15+ Mac Catalyst 13.1+ tvOS 13.0+ watchOS 6.0+
and no need to implement any other compression methods and levels, except LZMA
method and compression level 6
, then I would like to recommend to take a look: https://developer.apple.com/documentation/foundation/nsdata/compressionalgorithm/lzma
If not, then you can take the only C
part of original SDK (Swift
works fine with C
code) and implement LZMA
and/or LZMA2
compression methods with any settings. Here the reference: https://github.com/OlehKulykov/LzmaSDKObjC/blob/master/src/LzmaSDKObjCBufferProcessor.mm
I was assessing PLzmaSDK to see if it could be useful for my Swift based project which uses a protocol to abstract over (stream) compression implementations, a bit like this:
Possible solutions that I can see for PLzmaSDK to support this kind of interface:
InStream.init(stream:)
public, so I can do all the dirty work mapping back and forth between@convention(c)
and Swift callbacks.InStream
accepting Swift callbacks.Which of these sounds more acceptable for the PLzmaSDK project?