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

[Kevin Krammer]

On Wednesday, 2009-11-04, nf2 wrote:
> On Tue, Nov 3, 2009 at 2:43 AM, Aaron J. Seigo <aseigo at kde.org> wrote:

> > as Will noted, you are indeed fighting against the current here and we
> > are simply not interested in taking steps backwards in the user
> > experience just to win a phyrric victory that lets us say "we share a VFS
> > layer".
> 
> This highly integrated desktop is also a kind of phyrric victory. At
> least where it crosses the path of basic application infrastructure
> (which KIO is certainly about). As it's sort of assuming a platform
> where there isn't one.
> 
> However,
> 
> * ftp
> * sftp
> * smb
> * nfs
> * fish
> * dav
> * network
> * archives (zib, tar, iso,...)
> * bluetooth
> * cdda
> * camera
> 
> Those protocols aren't that intervoven. Therefore it should be easier
> to get them into a more "platformy" layer.

The first ones need at least athentication and proxy integration, some of the 
others should be OK if it is ensured that KDE and the VFS facility use the 
hardware managment facilities of the system.

> This should improve the unlucky relationship which KIO currently has
> with those protocols:
> 
> * Those users which can be satisfied with a pure KDE desktop (KDE apps
> only), probably don't need to work with file-servers a lot.

Or the probably only use KDE apps for non-local files.

> * And those users who need that feature, can't use KIO, because they
> are running a very heterogenous application base.
> 
> > all is not lost, however. as i've mentioned numerous times in discussions
> > on IRC there are several related places we can work on broad integration
> > that have NONE of the complexity or downside implications of a "Grand
> > Unified VFS Layer" have. this includes things like a shared wallet
> > system, a shared cookies storage system, a shared "places" system, etc.
> > those things which are not yet standardized and do cause REAL issues with
> > the user experience today.
> 
> What worries me, is that there isn't even a plan for the VFS layer.
> Because getting there definitely has quite a lead time.

It has been tried several times, but VFS has some many dependencies on other 
parts of infrastructure that it requires those to be shared first, e.g. 
authentication storage (see above).

> * If GVFS turns out to be the solution (unfortunately nobody else has
> evaluated it), then it can't adjust to that instanly. Like making URLs
> of certain protocols QUrl compatible, getting rid of a little gconf
> dependency, and perhaps fixing other little glitches we don't even
> know about...

I wouldn't worry about URI imcompatibilities too much, requirements for URIs 
should be pretty comparable for all URI capable libraries.

Dependencies are IMHO even less an issue since the process separation 
effectively shields either side from dependencies of the other.

> * 3rd party apps and toolkits also need time to adopt an VFS layer. Qt
> in particular, because it lacks an async file-IO API.

I think Qt does have that, at least it had in Qt3 (I wrote a KIO bridge back 
then :))

> So what i'm saying: This doesn't have to happen tomorrow, but there
> needs to be a plan. Not deciding means wasting many years...
> 
> So my propsal is: Lets try to do a GVFS port, including the places
> model, just enabled when KDE apps are running on Gnome. Then we get a
> clearer picture how well that works and where the problems are.

Hmm. What about implementing GVFS support as an additional API, i.e. not 
changing or replacing any KIO internals?
AFAIK this is what happend on the GObject stack, i.e. they didn't change 
gnome_vfs to sit on top of GIO.

Cheers,
Kevin

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20091104/37522700/attachment.sig>