Re: gvfs status report

[Alexander Larsson <alexl redhat com>]

On Tue, 2007-02-20 at 21:46 -0500, David Zeuthen wrote:
> On Thu, 2007-02-15 at 16:54 +0100, Alexander Larsson wrote:
> > Apps talk to the main daemon using the session bus, but most file
> > operations are done using direct peer-to-peer dbus connections between
> > the
> > clients and the mount daemons. Just send a request over the session
> > bus to set up such a peer-to-peer connection, then send normal dbus
> > messages over that connection instead. In most cases this should be
> > fast enough for normal use. However dbus isn't a good protocol for
> > bulk data transfer, so when we're actually reading or writing file
> > content we pass a unix socket fd over the dbus 
> 
> How do you actually pass a socket fd over dbus? (pretty sure it's not
> possible nor even desirable; see below)

Neither is it there a way to set up a peer-to-peer dbus connection, so
gvfs has to do this manually. It does so by having a method call that
returns an address string that is then passed to
dbus_connection_open_private(). (It looks like a typical
DBUS_SESSION_BUS_ADDRESS env var value).

Now, we actually pass two such strings, one we open with dbus, and the
other we open manually to pass fds over.

> > and use a custom binary
> > protocol over that. This lets us do file transfers very efficiently.
> 
> So one thing to keep in mind is that, just like we do for $DISPLAY, we
> want to forward $DBUS_SESSION_BUS_ADDRESS (possibly rewriting the
> address to use TCP like we do for $DISPLAY) when you ssh into another
> box. This means that applications, physically running on another box but
> display on your local screen can participate in e.g. inhibiting the
> screen saver / power management daemon and consume other session
> services too. Such as service from the VFS :-)
> 
> Stepping a few steps back, I guess one interesting question is really
> what *should* happen. 
> 
> So here's a user story. 

Clearly, accessing file:/// should always access the local filesystem.
However, there is nothing that says we can't have a mountpoint like
rfile:/// (or whatever) that proxies normal paths from/to the system
running the dbus session bus.

In such a case we'd have to fall back not only to sending file contents
over dbus, but to actually send it via the session dbus daemon instead
of peer-to-peer. This will be insanely slow, because the kind of i/o
done doesn't pipeline well with the large latency that this will give.
For instance, the current gnome-vfs daemon uses peer-to-peer dbus for
sending file contents, and gvfs is 250% faster than it when reading a
file over smb:///. I imagine a similar 250% slowdown just going via the
session bus, and many times slower going over a ssh encrypted tcp-ip
connection.

But still, it might be worth it in some cases, like in your usecase. On
the other hand, in many usecases you're not interested in accessing the
shares of the other computer, but want to instead e.g. access an smb
host on the network of the logged-in-to computer. In this case the vfs
forwarding will actually be hurting.

Your examples show shares from both local and remote. That will be truly
hard to do. How do you find the "other" gvfs-daemon if you can't just
look at the session bus env var? How do you know which daemon to talk to
for smb:///foo/bar? Plus, any "global" state in the gvfs system gets a
lot more complex. Any solution would probably leak out heavily into the
API making it cumbersome and complicated for a very limited usecase.

Anyway, I think its definately possible to have gvfs fallback on pure
dbus communication if local access is not possible, and add a way to
access the files of the remote machine via rfile:///. It will be slow as
ass, but work. (Of course, there isn't even a tcp/ip transport in dbus
atm, so this will be in the star-trek future.)

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's an ungodly amnesiac matador with a winning smile and a way with the 
ladies. She's a sarcastic psychic archaeologist from the wrong side of the 
tracks. They fight crime!