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

[Benoit Jacob]

I'm still not sure if I should post this as I'm incompetent on KIO and
on GVFS, but precisely, perhaps it is useful that i mention why i
believe that this debate needs to be reframed as the solution, in my
humble opinion, lies far beyond KIO and GVFS.

The problem, if you ask me, is that there is a whole world of software
out there that has no interest in using either KIO or GVFS, and will
only use the native OS's VFS. Thus, a KIO-GVFS integration doesn't do
much to unify the VFS systems used across all the programs that run on
any of our machines.

Here's my proposal to unify KIO, GVFS, and the native OS VFS when
possible, while keeping the existing features when that is not
possible, without requiring one party to use the other's
infrastructure, and all transparently to applications.

***

A. First let's work under the simplistic assumption that all OS's that
we need to support have a native VFS that is good enough to allow
mounting KIO and GVFS into them.

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".
3) Reimplement the KIO and GFVS client libraries as just accessing
this mount point, using this name mangling, so that there's no API
change at all for KDE and GNOME apps.

Thus at this point the "Linux desktop" has a universal VFS accessible
as part of the native VFS by any program without any dependency, and
that can be transparently implemented either by KIO or by GVFS (each
disto would choose according to own preference), that should be
transparent to the user.

***

B. I dont actually know if that idea of mounting KIO/GVFS can work on
all OS's that we need to support. Here is an idea of what to do if
some OS can't do that:

We could still do A. with only this little difference: the KIO and
GVFS client libraries could, on these particular platforms, directly
access respectively KIO and GVFS libraries. Thus on these platforms,
nothing would change from today's situation, there would be no
KIO-GVFS integration, but that wouldn't be a big deal. (KDE-Gnome
integration doesnt matter that much on e.g. Windows, if we could have
it on linux we'd be happy already)

Thanks for reading,
Benoit

2009/10/29 nf2 <nf2.email at gmail.com>:
> On Thu, Oct 29, 2009 at 4:17 PM, Will Stephenson <wstephenson at kde.org> wrote:
>> On Thursday 29 October 2009 13:14:46 Kevin Krammer wrote:
>>> I agree. Is the problem that this is a too high level place to support a
>>> different data source or the way the change is implemented?
>>
>> While I respect the effort, my problem with it is that it adds an IMO
>> unnecessary extra layer of abstraction, adding to the burden of maintainers
>> who are already spread thin in this area of kdelibs.
>>
>
> Yes, i'm aware of both problems...
>
> 1) The extra layer of abstraction seems to be the only way to make
> progress without breaking up KIO as an important technology for KDE.
> Therefore i'm just delegating a bunch of protocols. And as KIO can
> abstract libsmbclient, libssh or POSIX, it can certainly adopt another
> VFS.
>
> 2) The impact on maintainability - i guess that's hard to predict. It
> might as well have a trade-off, as a lot of work would be "outsourced"
> to Gnome developers. And that technologies grow better with the number
> of participants, that's a kind of  credo of FOSS...
>
> However the biggest problem is of course, that my proposal is touching
> the spirit of the KDE project: The desire for independence and
> individuality...
>
> Norbert
>