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) Desktop File system Volumes on bar (the remote computer this application is running on) ------------------------------------------------------------------- Super NAS Desktop 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. David _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list