Feature changed by: Michael Löffler (michl19) Feature #120115, revision 41 Title: Common Virtual File System Support openSUSE-11.1: Rejected by JP Rosevear (jproseve) reject date: 2008-07-21 13:06:16 reject reason: Lack of time before feature freeze. Priority Requester: Important Projectmanager: Important openSUSE-11.2: Rejected by JP Rosevear (jproseve) reject date: 2009-08-21 08:47:14 reject reason: Past feature freeze deadline Priority Requester: Important - openSUSE-11.3: New + openSUSE-11.3: Evaluation Priority Requester: Important Requested by: Joachim Werner (joachimwerner) Description: KDE and Gnome both use their own virtual file system layer to access protocols like SSH, WebDAV, FTP, or SMB (KIO slaves vs. gnome-vfs). This functionality should be available from all major desktop applications on both desktops. Different approaches could be taken: * Implement a lower-level VFS layer that can be used from all applications. This approach has obvious limits because all remote file systems would have to be "mounted" locally, which is not as flexible as accessing them via URLs. * Separate file loading and file storage from the application cores and use the desktop environments' native file dialogs. This approach has worked quite well for some applications (e.g. OpenOffice.org, Sodipodi), but may be a painsome process for others. * Use the useful parts from the non-KDE/non-Gnome applications and write new, native applications using those parts. This has been done with the Gecko rendering engine. Another example is gphoto2, which used to be a GTK application, but now is a library that is used in Gnome and KDE digital camera management frontends. How could we reach that goal? * KDE and Gnome developers at Novell should cooperate to develop a guideline for 3rd party developers. * Where possible, tools should be provided to help developers with using the native dialogs. Discussion: #1: Joachim Werner (joachimwerner) (2006-02-14 15:30:07) FUSE and user space filesystems like fusesmb or fuse_kio can deliver this. We need to put some effort into this post Code 10. #2: Stefan Behlert (sbehlert) (2008-05-21 21:15:25) Michael, you did some evaluation wrt. KDE/GNOME using common stuff. Anything helpful to add? #3: Gary Ekker (gekker) (2008-05-29 14:35:45) Given Novell and the communities recent investement in gvfs and the fact that KDE4 isn't using gvfs, I'm going to reject this one. #4: Michael Meeks (michael_meeks) (2008-06-03 11:14:21) Sure - this is a great direction to go in. Wrt. the different approaches - I want to use this as an opportunity to share code & reduce bug fixing / sustain costs: and of course to unify the ISV platform. I'm not that enthusiastic about FUSE from this angle: I would prefer a single implementation that can be compatibly wrapped by both existing KIO and GIO APIs. In addition, I believe we need to unify the wallet / keyring pieces since network IO slaves are fairly useless without that. #5: Joachim Werner (joachimwerner) (2008-06-06 11:37:22) I'm not quite sure I understand why this request is closed for 11. The problem persists, and AFAICS my initial description is still valid, regardless of the technology switch to gvfs on the GNOME side. In addition to that gvfs does not address the problem of making files available transparently to non-GNOME or even non-GUI apps (think vi), or does it? Please either reject it for time reasons and move it to a later version or even better address it for 11, but we should not close and forget about it, as the pain is still there for any user of a desktop that runs at least one major application from the "other side" or from the pre-GUI times. #6: Michael Meeks (michael_meeks) (2008-06-06 12:43:31) (reply to #5) Sure - I want to see this in sled11 too, and we have a plan to investigate this: lets not close it now. #7: Gary Ekker (gekker) (2008-06-09 08:37:43) (reply to #5) GVFS does make files available. At least you can tab-complete a path on a remote host when entering the path for scp for example. #8: Michael Meeks (michael_meeks) (2008-06-09 16:40:05) (reply to #7) Gary: the advantage of switching to a common IO subsystem is that it would make both KDE & Gnome equal peers in terms of their device access: it would also reduce our costs wrt. long term maintainance, and make things far easier for ISVs to integrate with both desktops in one shot. The fact that GVFS works, or KIO works in a given place is not that relevant here :-) #9: Norbert Frese (nf2) (2009-06-01 02:10:36) Just to mention it: Here is some experimental work, which tries to address this problem: http://live.gnome.org/KioGioBridge It's not that hard to run KIO on top of GIO/GVFS - but to make it neat, the dependencies of GVFS need to be approached as well. Particularly gconf and gnome-keyring. The latter could perhaps be tackled by making the KDE password manager GUI "dualistic" (allow to peek into both password managers - KWallet and Keyring daemon). #10: Will Stephenson (wstephenson) (2009-08-24 13:45:21) I agree that this will be nice to have but it's out of scope for an SP.  By replacing a core part of the platform with an experimental compatibility layer we would be replacing reliable and painstakingly maintained upstream code with something new that will run into every API corner case and badly specified behaviour, something we have to maintain ourselves, and which has not had any testing in openSUSE. IMO if we do this, we should do it right, upstream by proposing a common standard and taking it when it has matured there. KWallet is being ported to a standardised gnome-keyring backend so this will be easier in future. -- openSUSE Feature: https://features.opensuse.org/120115