Re: VFS for legacy apps (was: gvfs status report)

[Alexander Larsson <alexl redhat com>]

On Thu, 2007-02-22 at 14:22 -0600, Hans Petter Jansson wrote:
> On Thu, 2007-02-22 at 13:51 +0100, Alexander Larsson wrote:
> > On Thu, 2007-02-22 at 12:38 +0000, Damon Chaplin wrote:
> 
> > > You're probably always going to need type, server and share though, so
> > > maybe you can make it a bit more readable:
> > > 
> > >   ~/.mounts/smb:$server:$share/dir/file.txt
> > > 
> > > Extra options can go on the end.
> > > 
> > > Also I'd probably avoid ';' just in case bash goes anywhere near it.
> 
> > Sure, those are requred. But say we have two optional things, like user
> > and domain, as in smb:server:share:user:domain. But what do we then do
> > if user is unset, but domain isn't. I guess one could do
> > smb:server:share::domain. Still, it requires very specific handling of
> > each type of share with a specified option order etc. A key=value
> > approach is more generic.
> 
> I suppose
> 
> ~/.vfs/smb:$server:$share/dir/file.txt:option=$value:option=$value

You mean 
~/.vfs/smb:$server:$share:option=$value:option=$value/dir/file
I assume?

> is a workable compromise. It might even be what Damon was indicating.
> Now that we're picking on details, I'd say that .vfs or .gvfs would be a
> better base directory than .mounts too.

This would work, and would look better. It still requires specific code
for each possible backend to map from path back to the mount info
though. (i.e. you need to know that for smb the first two items are
server and share.)

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's an obese neurotic vampire hunter with acid for blood. She's an artistic 
psychic schoolgirl who inherited a spooky stately manor from her late maiden 
aunt. They fight crime!