Interesting. We should *definitely* do this for the 'Connect to server' dialog. When the SSH protocol is selected the host field could have a drop down prefilled with these discovered SSH hosts.

As far as the Network area. It seems that we can't discover the shares this way, just the SSH hosts. But I guess that's what happens (or is supposed to happen) for Windows networks too.

I have a feeling that we need to decide what the Network area should 'be'. As you pointed out, it's currently rather aimless and awkward. If it is a list of hosts that (can possibly) contain file shares, then yes, adding discovered SSH hosts there makes sense.

thanks for taking this up :-)

using the ssh protocol to discover hosts doesn't have a concept of "shares" per se. (windows networks, on the contrary, do have explicit shares.)

if we want to display "shares" inside a host instead of just showing its root directory (and i take it we do, as we're not even treating / as the entry point locally), we could:

first and foremost, offer ${HOME} and / as entry points or "shares". having home accessible is especially important, as it can easily happen with remote systems that the user doesn't know where his home is. (think of university servers -- /u/user5/${USERNAME} is not where i'd look first)

for everything else, we'd need to gather information about the remote system, and keep in mind it's not necessarily linux (again, think university servers). i'm not even sure we can infer ${HOME} from what gvfs gives us. if i were to make a wish list, it'd contain:

* ~
* /
* remotely configured xdg user dirs
* the platform's "favorite directories" (eg nautilus bookmarks. probably feasible only if they are kept in a way similarly standardized as xdg user dirs)
* explicitly shared directories (eg gnome's user file sharing, subject to similar conditions as the above)
* removable media (like locally)
* other users' home dirs, provided they are readable

discovery of those should be possible by means of reading files via sftp://, provided we get access to the remote environment variables (most importantly HOME, but also XDG_CONFIG_HOME). again, whatever discovery is used, it needs to tolerate the most exotic remote environments. (the reason i'm emphasizing on this is that i'd love the universities' "how to make my windows pc connect to my student shares" pages to have a gnome equivalent that says "when inside the building, just go to 'network', otherwise press 'connect to server' and enter that address", and show how easy it can be.)

as breaking sftp://hostname/absolute-path-without-additional-leading-slash style urls is probably a bad idea, i suggest those avahi-discovered hosts be presented in sftp-discovery://, and each host's "shares" in sftp-discovery://hostname/; the objects themselves could then be listed as the respective sftp:// urls.

just a related note, as i forgot to mention it before:

palimpsest / gnome-disk-utility used to (before 3.4, when they switched to udisks2) have a feature to inspect remote hosts, that would help with the "removable media" item. they even had avahi host discovery there, but relied on explicitly calling ssh in a slightly error-prone way. no matter how we'll get the remote environment variables, there'll be some overlap between these two projects.

i'm a bit sceptic of this myself, though, as it smells like "remote command execution via vfs", which is really not what a vfs is for. maybe the vfs could expose in a mountpoint's metadata how to connect there for command execution, and possibly even share the location of a running connection multiplexer.

(In reply to comment #1)
> Interesting. We should *definitely* do this for the 'Connect to server' dialog.
> When the SSH protocol is selected the host field could have a drop down
> prefilled with these discovered SSH hosts.

It is completely different soon. See bug 682637 . We want to use the browse functionality more heavily instead.

> As far as the Network area. It seems that we can't discover the shares this
> way, just the SSH hosts. But I guess that's what happens (or is supposed to
> happen) for Windows networks too.

When I have remote login enabled on OS X I see it appear in my Network place as a host. I'm not sure sftp works with the OS X version of remote login since I haven't been able to connect yet. (have to look into that)

> I have a feeling that we need to decide what the Network area should 'be'. As
> you pointed out, it's currently rather aimless and awkward. If it is a list of
> hosts that (can possibly) contain file shares, then yes, adding discovered SSH
> hosts there makes sense.

Why is it aimless? I think it is a place to connect to file shares nearby. And I think we should probably consider making hosts with SFTP mounts available appear there.

Is there a way to tell if a ssh service supports sftp?

(In reply to comment #4)
> Is there a way to tell if a ssh service supports sftp?

the list of services at [1] mentions an sftp-ssh service along with a plain ssh service, and debian will use it if they decide to announce ssh[2]. oddly enough, it seems ubuntu currently doesn't announce anything by default any more.

[1] http://www.dns-sd.org/ServiceTypes.html
[2] http://bugs.debian.org/389338


in other news, i just read a debian bug report on the issue at hand[3], and found out that at least as of gnome 3.4, the original bug is already almost solved:

* hosts show up in network:// provided they export _sftp-ssh._tcp
* when opened, a mount point is create and nautilus goes to sftp://${HOSTNAME}/
* when opening the created mount point, it goes to sftp://${HOSTNAME}/home/

the remaining issues of the original bug report are:

* a list in the "connect to server" dialogue (seems to be obsolete anyway)
* support for other protocols (webdav, nfs) -- didn't check.

other remaining issues from the later posts are walter's shares (with my list of shares i'd like to have -- the current way of opening / from network:// but ~ from the bookmarklet seems nonintuitive to me), and the perceived aimlessness of the network:// location.

if there are no objections, i suggest setting this report to fixed and creating distinct bug reports if someone wants to persue the remaining issues.

[3] http://bugs.debian.org/680639

Yeah I don't think there is anything actionable here at the moment.