Re: GZip{In,Out}putStream in GIO?

["Freddie Unpenstein" <fredderic excite com>]

From: "Mikkel Kamstrup Erlandsen", Date: 04/08/2009 00:22, Wrote:
> On Mon, 2009-08-03 at 07:58 -0400, Freddie Unpenstein wrote:
>> Archiving formats would be better supported by GVFS, wouldn't they...?
>> Treating an archive as a virtual directory.
> I'm pretty confident that in 98%[1] of the use cases the developer
> needs to know that this is really about an on-disk file and not a
> directory. Bear in mind that I would need to do a
> g_file_enumerate_children() and open streams on nested URIs I get from
> the GFileInfos returned by the GFileEnumerator.

I understand this...  I don't know the details, but I had a suspicion it would be a pain.  However, it may be possible to abstract some of that away to return a simple list of names, or the stream corresponding to a given name...?


>> However, zip has a few compression formats, rar compression can be
>> applied both before and after bundling of the files (a rar "solid
>> archive" is similar to a tar.gz archive).
> Remember we can't build anything around RAR format due to incompatible
> licensing, except of the file-roller way (spawning external commands).

It was more an example than anything...  I have heard there are licencing issues with RAR...  It's the fact that the compression can be on either side of the archive structure that I thought worth bringing up...  Same as for tar/(g|b)zip...  You can quite conceivably have a tar archive of gzipped files.


> libarchive can be easily used as a "filter" between two streams,
> transparently decoding incoming data. This should be really implemented
> as an extension, we don't want to have another dependency in glib.

That sounds fair enough...  A quick glance over at libarchive, and it seems to do pretty much everything required (can't tell if it handles concatenated gzipped files).  But embracing it looks like duplicating a fair chunk of functionality.  I wonder if it would be better to do it over in a more GLib/GIO-esque style than trying to embrace it.  GIO streams can completely replace the I/O layers at both ends of the libarchive engine, while compression and at least some of the archive format handling is done by external libraries.  It really doesn't look like there's much left for libarchive to do, apart from format detection, at least as far as I could tell from my quick look over the documentation.

Anyhow...  Wish I'd known about libarchive a while back.  I really have to practice my Google technique...  :(


I do, though, wish there was a compression library that was able to snapshot an in-progress compression, allowing you to "rewind" to a saved state and continue from there.


Fredderic

---

	Toupee
	Find toupees to help you look your best! Click now!
	Click Here For More Information