Re: VFS integration with kernel mounts

[David Zeuthen <david fubar dk>]

On Thu, 2007-05-03 at 10:14 +0200, Alexander Larsson wrote:
> The way a normal application uses gvfs is by the gio apis. Essentially
> you hand over a uri, and this uri is parsed by custom uri-type specific
> code into a mount specification (info about a gvfs mountpoint) and a
> path into it. Each operation on this mount is sent to the right mount
> daemon for the particular mount, and if its not running it will just
> give a NOT_MOUNTED error.

Thanks for the explanation. Do you expect apps using the gio API's to
save the URI's (for e.g. recent files or a media database)? If so, they
need to handle NOT_MOUNTED the next time they start up and load the URI
from recent-files etc... 

> In the case when the media was not mounted one would get
> NOT_MOUNTED errors from gvfs. These errors are normally handled by the
> file manager or the file selector and 

Is there utility API so these apps (and both the file chooser and
Nautilus) can use the same code [1]? The implementation of such
(blocking) utility API should probably just be an D-Bus session bus
service [2] (that would/could be activated on demand) under the hoods..

     David

[1] : One of the things I dislike about current gnome-vfs is that apps
themselves get to display the error dialog which is a source for
inconsistencies... For example, the one used by Nautilus and the one
used by gnome-vfs-daemon don't look the same.... which is annoying.

[2] : Since mounting/connecting the "media" might require asking for
credentials you really want the code asking for this to be in a separate
process... much like how gnome-keyring works ... in the future that
helper process can be labeled with a trusted security context (or on
non-SELinux you can look at exe paths) which means you can protect that
window from input-event-stealing and even apply fancy WM decorations
etc.. e.g. all the XACE work.