On 3 July 2011 13:51, erik quanstrom <quans...@labs.coraid.com> wrote: > what i was trying to say is that even in that case, i think gio is a weak > model. it goes back to the vms/dos days where the method of access > becomes part of the name. that is, i need to know if it's accessed via > http or ftp or local to access a file. further, i can't have a path like > /usr/quanstro/remote/http://my.other.site/some/path. i have to attach > devices at the root.
Yeah, that's true. Still, that's not *too* different from Plan 9 binding: you have to know the protocol in order to mount a drive, after all. I know very little about GVFS, admittedly, but it would make sense if you *could* run the equivalent to Plan 9's bind(), so you'd say, % bind http://example.net/some/path ~/example That's pretty much the same as running the appropriate fileserver and then binding the result, only GVFS works out what daemon you need. > and i'm pretty sure i can't modify what's accessable > without recompiling everything that uses the gnome vfs stuff. I think you can add more filesystems without recompiling anything, though I don't know for sure. I think it works quite well conceptually, though I'm really not a fan of linking everything into DBus and so on. Still, in terms of bringing Plan 9 to a "wider audience", GNOME might be a way. Of course, it would be rather a lot nicer if Linux could just work out its issues and stop relying on CAP_SYS_ADMIN, but that doesn't seem likely. On the topic of Plan 9, I was thinking an interesting fileserver would be one which, if you access '/uri/http:/example.net', looks up in a table the fileserver required for 'http:', and hands the request over automatically. That way you get the same as GVFS, only without the DBus snafu. I don't know if anyone's already done that. Thanks, cls
