Re: gvfs status report

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)

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

Suppose I'm at host foo and log into host bar over SSH with both X /
session bus forwarding (this is perhaps just clicking an icon that my
sysadmin set up). Perhaps I log into this host because I need to run
some app which requires lots of computational power and host bar has
1024 CPU's and host foo is my workstation / laptop. Now, let's assume my
app on bar is using the latest and greatest GNOME stack and so is my
laptop foo. I run my simulations (say I'm a scientist) and wants to save
a file with a digest / report of the simulations. I hit the save icon.

Now the file chooser comes up. What does it look like? 

Right.. well, according to your proposal the app on host bar will start
talking to the gvfs daemon over the session bus. In this case this will
be forwarded over TCP/IP since the gvfs daemon lives at host foo. So the
list of volumes returned will include, most probably, just the local
volumes available on host foo. This might include say the user's USB
stick. This is actually beneficial for the user in this specific
example; he wants to save the 100kb report from the simulation.

(Implementation-wise, passing fd's over dbus is now no longer
technically possible (doubt it's possible even in the local case) so I
guess your implementation needs to fallback to doing I/O over D-Bus.)

Actually I think this is desirable. Surely the file chooser on the app
on bar needs to be aware of this and perhaps show these volumes on the
list on the left

 Volumes on foo (the computer you're in front of - slow!)
 Sandisk Cruzer 40MB USB stick
 Super NAS on bar (SMB)
 File system

 Volumes on bar (the remote computer this application is running on)
 Super NAS
 File system

  (need to trim down the text in parenthesis above - but the message
   is very important to show so the user can make an informed choice
   of where to save his report)

Of course all this involves marshaling I/O over TCP/IP. That might be
slow. But such is life.

(bonus question: can we automatically detect that "Super NAS on bar
(SMB)" is actually a local file system if the app running on bar wants
to save to it? Cuz that would be somewhat nice!)

Btw, I don't think this use-case is at all "weird" and I think shiny new
gvfs should be able to at least have a story for it. Of course, one
option is to hide the GVFS D-Bus service under a library that just
refuses to talk to the D-Bus service unless it's local. But that's
hardly optimal either.

Anyway, this is probably a difficult question. Sorry.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]