Mailinglist Archive: opensuse-features (365 mails)

< Previous Next >
[openFATE 120115] Common Virtual File System Support
  • From: fate_noreply@xxxxxxx
  • Date: Mon, 15 Mar 2010 13:07:58 +0100 (CET)
  • Message-id: <feature-120115-44@xxxxxxxxxxxxxx>
Feature changed by: Andreas Jaeger (a_jaeger)
Feature #120115, revision 44
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: Evaluation
+ openSUSE-11.3: Rejected by (a_jaeger)
+ reject date: 2010-03-15 13:07:55
+ reject reason: This would be nice indeed but I'm not seeing this happen
+ at the moment.
Priority
Requester: Important

Info Provider: (Novell)
Info Provider: (Novell)
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

< Previous Next >
This Thread
References