Re: VFS for legacy apps (was: gvfs status report)
- From: Alexander Larsson <alexl redhat com>
- To: Damon Chaplin <damon karuna eclipse co uk>
- Cc: "gnome-vfs-list gnome org" <gnome-vfs-list gnome org>, "gtk-devel-list gnome org" <gtk-devel-list gnome org>
- Subject: Re: VFS for legacy apps (was: gvfs status report)
- Date: Thu, 22 Feb 2007 13:51:59 +0100
On Thu, 2007-02-22 at 12:38 +0000, Damon Chaplin wrote:
> On Thu, 2007-02-22 at 03:10 -0600, Hans Petter Jansson wrote:
>
> > However, the first method you describe:
> >
> > ~/.mounts/type=smb-share;server=$server;share=$share/dir/file.txt
> >
> > sounds perfect. It's rich (we can get back the mount info later),
> > extensible (we don't have to figure out the entire set of potential
> > mount options in advance) and fairly simple (the root nodes are all
> > direct children of ~/.mounts).
>
> 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.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander Larsson Red Hat, Inc
alexl redhat com alla lysator liu se
He's a hate-fuelled arachnophobic Green Beret who knows the secret of the
alien invasion. She's a cynical out-of-work femme fatale from out of town.
They fight crime!
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]