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

[David Faure]

On Sunday 01 November 2009, Benoit Jacob wrote:
> 2009/11/1 David Faure <faure at kde.org>:
> > On Saturday 31 October 2009, Luciano Montanaro wrote:
> >> On venerdì 30 ottobre 2009, David Faure wrote:
> >> > On Friday 30 October 2009, Benoit Jacob wrote:
> >> > > 1) Make sure that both KIO and GVFS can be mounted into the OS's
> >> > > native VFS. 2) Make it so that KIO and GVFS agree on a filesystem
> >> > > layout (a "name mangling" if you want) so that the same filename can
> >> > > be used regardless of the choice of KIO or GVFS. By a "name
> >> > > mangling" i mean a translation from addresses like
> >> > > "sftp://user@server/path" to addresses like
> >> > > "/mountpoint/ssh/user/server/path".
> >> >
> >> > Please keep in mind the difference between sync and async APIs.
> >> >
> >> > You download a file over FTP. KIO is async: the application remains
> >> >  responsive, you get a progress dialog. The "native VFS" is most of
> >> > the time used in a blocking way. fopen,fwrite,fclose. Which means the
> >> > application freezes until the FTP server sends the whole data. Not
> >> > good. A remote filesystem is NOT like the local filesystem.
> >>
> >> Well, the filesystem calls are synchronous, yes, but that's not a
> >> problem for the file:// kioslave, is it?
> >
> > Right. But my point is that people saying "by mounting stuff into the
> > filesystem we can allow even non-KDE non-Gnome applications to benefit
> > from kioslaves" are omitting the fact that those non-kde non-gnome
> > applications would then use synchronous API, and would block for a very
> > long time.
> > So a KIO-like API is needed. So mounting things into a filesystem
> > mountpoint doesn't get you anything.
> 
> But what about my other mail above, where I mentioned that Linux 2.6
> already has an async file io API? It's not our fault then, if these
> apps use sync io when they want async io; or if they only want to use
> sync io, then they shouldn't expect to take advantage of everything.

Have you ever written code using that async file io?
I have.
And that's why I'm telling you: hoping that all apps out there are ported
to it is -really- irrealistic. Not more than 1% of them will.
What's the point in using filesystem mount points (and a POSIX API)
if people can't use the standard POSIX API (fopen/fread) on top of it?
This is nonsense.
If the apps need porting, then they might as well be ported to KIO,
or, because we were defeated at the initial goal from 1996 to unify the free 
desktop, ported to some standardized API that sits on top of KIO & GIO,
or something.
Who is going to port `cat` to async io for the use case of remote mountpoints,
to avoid that it hangs like it does on NFS mounts? Nobody.
Meanwhile, `kioclient cat` took 10 lines of code to implement,
with the nice KIO API.
My point: remote filesystem stuff doesn't belong to the POSIX layer.

> Also note that many KIO slaves are pretty cool
> already with sync IO, for example audiocd://...

!? I don't see what you mean here. It's a kioslave, so it's in a separate 
process, so obviously it can't block the app. And since it's a kioslave,
it's not used synchronously by the app. So I see nothing sync about it.

> Moreover there was another reason why mounting stuff into the
> filesystem was nice: it allowed KIO-GVFS interoperability without one
> relying on the other --- "on an equal footing". There the idea was to
> reimplement that part of KIO/GVFS to use the async io API on Linux 2.6

I see much confusion between what sits on top of what....
On one hand there's mentions of "FUSE, on top of KIO/GIO", useful for non-kde 
non-gnome apps (but I say: wrong API for it), while you are saying
"KIO/GIO on top of FUSE" -- which makes even less sense to me.
What's the point in that? To use GIO protocols? nf2's bridge gets you just 
that, in a cross-platform way. And without the extra (and restricted) layer of 
indirection for the case where we're actually talking to a kioslave.
How do you pass metadata to a kioslave via a fuse layer?

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org).