Re: VFS integration with kernel mounts

[Alexander Larsson <alexl redhat com>]

On Thu, 2007-05-03 at 15:18 -0400, David Zeuthen wrote:
> 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... 

Yes, URIs are still the best thing we have for user visible and
persistent file identifiers, for all their ugliness.

> > 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..

Yes, there will be a common utility class for handling all mount
interaction.


> [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.

On the contrary, you want the authentication to happen in the client
that caused the authenticating i/o. That is because that client has to
display things the right way depending on its state. For instance, you
want dialogs to have the right parent, you want to handle modal dialogs
opening authentication dialogs right, and you want the dialogs to be in
the right window group.

One of the big advantages with the mount model in gvfs (as opposed to
gnome-vfs) is that we know when authentication will happed (at
mounttime) and can handle it in a sane way in the app. In gnome-vfs
authentication (including infinite blocking if the dialog appeared under
your window, or lots of dialogs if e.g. listing various mountpoints) can
happen at *any* i/o operation, which is not sanely handleable by the
app.


=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's a notorious Amish Green Beret who hides his scarred face behind a mask. 
She's a transdimensional motormouth schoolgirl looking for love in all the 
wrong places. They fight crime!