[Gambas-user] Question about the real scope of Gambas, and other on compatibility

[Rob]

On Saturday 01 December 2007 16:35, Benoit Minisini wrote:
> gb.compress works the same way as gb.db. It can compress and
> uncompress specific file formats provided that you write the
> gb.compress.XXX driver for that (gb.compress.zip in that case).
> Look in the source code of gb.compress.zlib to see how to write
> gb.compress.zip.

Well, actually, I did, and that won't work.  gb.compress.zlib and 
gb.compress.bzlib2 only provide an interface to handle "Unix 
compress" style files, which contain a single compressed file.  ZIP 
files are a whole filesystem, like tar files whose members are 
compressed (rather than the Unix way of an uncompressed tar file 
which is compressed as a whole), and need some extra virtual classes 
and collections to implement that stuff.  

For that matter, the fopen/fseek and in-memory compression methods 
provided in gb.compress.* aren't even analogous to any operations 
with a ZIP file: say you compress the contents of a variable.  What 
do you do with it then?  With gzip/bzip2 you just output it to a file 
and that's it.  With ZIP you need to create the archive and then add 
the file.  You also need separate open/seek functions for the zip 
file and for the files inside the zip file.  That's why I was 
suggesting gb.archive.zip.

> Anyway, I use directly the zip & unzip utilities via EXEC to
> uncompress and compress the OpenOffice files, so a specific
> component is not really needed for that.

Would you really accept a gb.odf component that relied on EXEC?  
Because my original proposed pcre component did, and because you 
disapproved, I ended up writing it in C, as I'm now doing with 
gb.zip.  

For that matter, why do we have gb.compress.zlib when gzip and gunzip 
are so trivial compared to zip and unzip, and could be much more 
easily used with EXEC?

Rob