KDE is not an OS platform... (And neither is Gnome)

[nf2]

On Tue, Nov 3, 2009 at 1:57 AM, David Faure <faure at kde.org> wrote:
> On Tuesday 03 November 2009, Kevin Krammer wrote:
>> On Monday, 2009-11-02, Oswald Buddenhagen wrote:
>> > On Mon, Nov 02, 2009 at 01:36:33AM +0100, Martin Sandsmark wrote:
>> > >  Søndag 1. november 2009 21.13.11 skrev nf2 :
>> > > > Read my "solution" number 2 above.
>> > > >
>> > > >> [...] aligning the behavior of protocol-handlers in KIO and
>> > > >> GVFS [...]
>> > >
>> > > Well, what's missing? It shouldn't be so hard, the format of the URLs
>> > > are well-defined by RFC 1738, and all the protocols I can think of have
>> > > standardized names (maybe in RFCs too? I'm too lazy to check, but this
>> > > is really a minor issue to fix...).
>> >
>> > if you manage to represent an object file in an ar archive in a tar file
>> > in a gzip file in an encrypted rar file on an ftp server as an url which
>> > every vfs understands then you have won.
>>
>> Hmm.
>> Since KIO operates on URLs as well, wouldn't have that the same limitation?
>> What would e.g. Konqueror display in its location edit for such a case?
>
> KDE3's KURL had support for that, using sub-urls. So the above would have
> looked like ftp://host/file.rar#rar:/foo.gzip#gzip:/#tar:/foo.a#ar:/foo.o
> assuming that all these kioslaves would have existed (they didn't)
> and that such amount of nesting was working (I don't think it did).
>
> In KDE4 I dropped it, mostly because the lack of caching in the ioslaves
> and the lack of reliable slave-reuse by the kio scheduler, meant that the same
> file was download over and over from the ftp site while you were browsing
> through its contents. Oh, and the data was copied between 6 kioslaves, in a
> case like the above. Really horrible for performance.
> (So I also dropped sub-urls altogether, since even making just the url parsing
> work with QUrl was some effort).
>
> So if someone feels like doing this again (users subscribed to bug 73821 will
> certainly love you), he would have to fix all of the above: sub-url parsing,
> caching in the remote slaves like ftp/smb/fish/ssh --- ok, so better, caching
> of file contents inside KIO somehow, when these files are used as archives,
> and finally doing the archive inspection without kioslaves, for instance using
> strigi streams instead. They are in-process, which is certainly much nicer
> than kioslaves when so many of them have to work together. We're missing a way
> to chain kioslave output with strigi streams, basically. Seems doable though.
> And now, to come back to the thread topic: think of how much more complex it
> would be to do the same on top of GIO (nothing against GIO itself, I mean: on
> top of something we have no control over)... Mind boggling.
>

GVFS does such things, but the notation is a not very beatiful:

this is pointing into an archive inside an archive on an sftp share...

archive:///archive%253A%252F%252F%252Fsftp%2525253A%2525252F%2525252Fuser%25252540www.server.at%2525252Fhome%2525252Fnorbert%2525252Ftmp%2525252Farch.tar.gz%252Funtitled%252520folder%252Far1.tar.gz/

as the archives are "mounted" (in the sense of GVFS), the directory
structures are cached.


Norbert