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

[Benoit Minisini]

On dimanche 2 décembre 2007, Rob wrote:
> 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.

Seems logic, as running a process for just matching a regular expression is 
too heavy.

But when you just have to unzip a zip file, and zip it back just once for 
generating an OpenOffice document, it is acceptable.

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

I don't know, I didn't make them. :-) If running an external process is not 
heavy relatively to the task, I usually run the process. Especially if this 
process is a GNU tool that is usually always or often installed on the 
system.

When you have to use an archive format (like tar.gz or zip), of course you 
need more features: browse the archive, extract a specific file from the 
archive, insert or replace a file in the archive... Actually I don't know, 
but I think then the command-line tool should provide these features, so that 
you don't need to use the underlying library for accessing this tool.

I usually prefer that, because I am lazy :-)

But maybe other people will have a real use of archive or compression 
management components. They must tell.

Regards,

-- 
Benoit Minisini