2009/8/3 Freddie Unpenstein <[email protected]>:
> From: Steve Fr-23;cinaux, Date: 03/08/2009 19:38, Wrote:
>
>> Bastien Nocera wrote:
>> > I could think of at least 5 types of compressions that would be useful
>> > to have without having to use a command-line tool to decompress:
>> > - gzip for anything and everything that can come from a web server (in
>> > my case, iTunes Music Store playlist parsing, or more widely, GOffice
>> > file formats)
>> > - zip for OpenOffice.org documents and Comic Books (evince)
>> > - 7zip/LZMA/Xz formats for Comic Books
>> > - Rar for the same as above
>> Aren't there two classes of file types there ? Compression vs Archiving
>
> Archiving formats would be better supported by GVFS, wouldn't they...?
> Treating an archive as a virtual directory.
>From an end user perspective I can see the value in this abstraction -
being able to browse into archieves, however from a developer
perspective I think I would mostly find it as an annoying abstraction.
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.
>From a programmatic perspective I like the Java approach much better.
Abstracting the ZipInputStream to general archives should be trivial
(and making it more GIO-stylish is also a task for the reader):
InputStream rawStream = new FileInputStream("/tmp/foo.zip");
ZipInputStream zip = new ZipInputStream(rawStream);
ZipEntry entry = zip.nextEntry();
System.out.println("Got zip entry: " + entry.getPath());
InputStream nestedStream = entry.getStream();
System.out.println("Entry contents: " +
nestedStream.readTheWholeBloodyStream());
// Do the zip.nextEntry() entry dance until we have read all entries
--
Cheers,
Mikkel
[1]: And because I include arbitrary made up statistics I
automatically loose this argument ;-)
_______________________________________________
gtk-devel-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
