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!
http://tagline.excite.com/fc/FgElN1g05cL012R3SRh8CWFbYT1xuTXgkfM2tibgFh5Lo8J77cLU8SCTbBO/
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
