[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: KIO filters, KGZipDevice etc.
From:       Waldo Bastian <bastian () kde ! org>
Date:       2000-10-20 15:53:01
[Download RAW message or body]

On Friday 20 October 2000 05:55, David Faure wrote:
> Following a discussion that started on kde-cvs after my import
> of KGzipDevice in kio_tar....
>
> I have just realised something very important.
>
> The QIODevice concept completely breaks network transparency.
> Devices (local files etc.) always have the data available. So you can
> call readBlock, and in return you have the data.
> OTOH, with KIO (and networks in general), you have to wait for the
> data to be ready. This just doesn't fit together.
> We could pull a hack like NetAccess, to make iodevice wait for
> data to be available before moving up, but this would suck (blocked
> user interface etc.).
>
> But the reason I chose QIODevice is because that's the way, for KOffice,
> to create a QDomDocument from anything, including a gzipped stream,
> without copying data all over the place as we do now.

What's wrong with the kio-filter stuff? asking for 
http://www.kde.org/file.gz#gzip: unzip's on the fly. If you want to have 
everything at once you can use NetAccess. If you want to do streaming you use 
a TransferJob and connect to the data() signal. khtml uses it to render 
images when they come in.

If you want random access you can't really use streaming network transparancy 
because it's very difficult to rewind your stream.

> a base class (KIO::Filter ?) that implements in C++ the concept of
> "available in" / "available out", implementations for gzip and bzip2
> available (whether in libkio or as shared libraries, dunno).
> kgzipdevice and kio_gzip could then both be based on that code,
> and in fact generalised to any kind of filter, so we would have in fact
> kio_filter and kfilterdevice, handling all sorts of compression.
> Hmm, that's a reason for the filters to be available as shared libs: this
> would make them available "by name" (instead of by hardcoded
> constructor calls).

E.g. a generalized C++ wrapper around the libz interface?

> Then KTar can provide a filterdevice on the underlying data, for KOffice.
> (I never liked a network-transparent KTar, it just doesn't fit the tar
> format, which makes it suck over slow connections).
>
> How to handle mimetype of compressed files (e.g. blah.png.gz, a.ps.gz or
> b.txt.gz) is still to be determined...... it has to be transparent in some
> cases (the application opens the file), but not in others (downloading and
> saving shouldn't unzip)....

metaData("nounzip") = true

Cheers,
Waldo
-- 
KDE/Linux, you make the choice.

[prev in list] [next in list] [prev in thread] [next in thread]