LiveCode Forums

Looks like the revZip functions could use some work.

http://forums.runrev.com/viewtopic.php? ... 528#p78528

I love finding comments like this (inrevzip.cpp):
NB: I'm not complaining - at least it's a comment.

Hmmm - sounds like that forum post is more about trying to compress/decompress data that isn't wrapped up in a container. As you say zip archives can compress in various ways (including uncompressed). I suspect the problem with gunzip there is the header/trailer aren't quite what is expected (perhaps the checksum isn't correct?). There's an enhancement request (I think from @Janschenkel) about extending the compress/decompress commands to take options so that you can control the format etc. and I think that would be the best way to go. (zip and gzip are quite different - zip is an archive format, gzip is just a compression format - i.e. you need to have done the archiving (e.g. tar) first).

I had a quick look at the revzip functions last night, and I can't see how the compression format is specified. The only format specification I found is ZIP_CM_STORE if the compression flag is False.

As I said above, I don't think anything is wrong with revZip here - what the original poster is trying to do with it isn't quite correct. You can either choose to store data uncompressed in a zip archive, or compressed - the former is if you already have compressed data (like PNGs, JPEGs etc.) which rarely benefit from a second 'deflate'. If you store data uncompressed, then it gets written out that way, and passed back to you verbatim (i.e. it doesn't try and decompress the data you gave it at any point).

The issue here (I suspect) is that of deflate options and the gzip header/footer he is adding to it not matching the format of the deflated data he is getting - or the data isn't wrapped in an appropriate way before being wrapped in a gzip header. I must confess I don't know enough of the details here. @Janschenkel mentions some RFCs here in the enhancement request:
http://quality.runrev.com/show_bug.cgi?id=10594

From my brief look - 'deflate' is the raw compression method, it carries no header/footer and then 'zlib' and 'gzip' wrap compressed data in headers.

Dear Folks,

RunRevMark is quite right in saying there is nothing wrong with the revZip functions (as far as I know). I was just trying to be creative in exploring ways to get around the lack of a deflate (from memory) function in LiveCode.

I have talked with the developer of the server-side code. The data is being compressed with a method that uses a zlib compress function that deflates the data and adds a 2 byte header defining the CMF (compression method and flags), and CM (compression method) as described in RFC 1950, at: http://www.ietf.org/rfc/rfc1950.txt.

The current client is written in Perl and used the Compress::Zlib module and it's inflate method to decompress the (in memory) deflated string. We would like to rewrite the client using LiveCode in order to provide a graphical interface and to also target mobile platforms.

I'm not sure if this might be considered a feature request, or what, but it seems reasonable that LiveCode should have, as many other languages do, an interface to the zlib library to inflate and deflate a string in memory. Can someone here provide some information on how to go about making this request? I would hate to lose the oportunity to continue learning and working with LiveCode because of this missing functionality, but that might be my employer's decision.

Your help is much appreciated.

Best Regards,

Daryl

@Daryl: We've had an enhancement request for this in the quality centre for a while... Maybe if we can catch @Janschenkel's attention (he was the person who originally filed it), we might be able to persuade him to take a look into implementing it (the primitives are already there, it's just a case of extending the compress/decompress functions...)

@RunRevMark,

Thanks for your reply. If I can help in any way, please let me know. I'm a fairly decent (if a bit rusty) C programmer, and totally unfamiliar with LiveCode's interfaces and APIs, but if I can help in any way I'd be glad to contribute some time.

Regards,

Daryl

Hmm, it's been a while since I looked into this; and I found a workaround for reading PNG pixel data by tampering with the header and trailer.
If my memory serves me well, the core payload for zlib and gzip compression is the same, but they wrap it in different ways.
Let me see if I can find some time to investigate this...
I know where to plop in the extra code, now it's a matter of figuring out what extra code to plop in there

Jan Schenkel.

Hi Jan,

Thanks for your reply. When you have the time you might want to look at the zlib utility functions that work with their stream-oriented functions. The API documentation is available at:

http://zlib.net/manual.html#Utility

Please let me know if I can be of any help, or assistance.

Best Regards,

Daryl