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

[Benoit Jacob]

ah and one more thing.

I can sense responses about "the kernel's VFS doesn't support this or
that important feature" coming soon ;) As in this blog post about GVFS
and FUSE (which also shows that, predictibly, people already had the
same idea that i was proposing):
http://blog.fubar.dk/?p=104

The answer is that, if really current kernels lack a particular
feature, then that's a perfect occasion to go talk to kernel devs!
Don't I seem to remember that recently (at GCDS?) one of them asked
you guys if you had feature requests? And as I said in previous
e-mail, on OSes where we can't communicate with kernel devs, just keep
the statu quo.

ok now i'm really getting back to stuff where i can be useful : that's
NOT that ;)
Benoit

2009/10/30 Benoit Jacob <jacob.benoit.1 at gmail.com>:
> 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
>>
>