A common VFS and a Common conf-system (Was: namespacing)
apenwarr at nit.ca
Wed Mar 2 03:04:40 EET 2005
On Tue, Mar 01, 2005 at 07:49:28PM -0500, Sean Middleditch wrote:
> On Tue, 2005-03-01 at 19:36 -0500, Avery Pennarun wrote:
> >You make this sound hard, but it's only as hard as you want to make it; for
> >example, the guys who invented NFS didn't want to make it hard, so things
> >like O_EXCL create, caching, locking, and unlink-while-file-is-open don't
> >really work right. If you leave off the details, you can make something
> And it shows in many, many places - there is lots of software that just
> doesn't work right on NFS because they expect defined behavior that
> works in an incorrect manner.
"Lots" is true, but it's very surprising how incredibly seldom you run into
this software. Many people in the world can and do boot and run their
entire systems over NFS. It's a feature of Solaris, and Linux can do it
> And, for D-VFS, it's moot, since we're not using POSIX - not worth
> arguing about, really. :)
You don't have to "use" POSIX. You just have to have a design flexible
enough to support POSIX semantics if necessary. Someone else can provide an
adaptor for POSIX *syntax* (ie. exact function calls), but if you don't
provide the few basic semantics needed, your system will be unnecessarily
incompatible. Why bother being incompatible if it costs you basically no
> >And then, if you're speaking a protocol that *can* be posix-compliant, you
> >can make it so. That's well worth it, because those fancy posix
> >restrictions are all there for very good reasons.
> But, most interesting protocols aren't. Accessing NFS isn't something
> D-VFS will ever do, since NFS shares will just be mounted normally.
> We're more interested in WebDAV, FTP, SFTP/SCP, etc.
Actually, that's not true. To this day, non-root users can't mount NFS or
SMB shares. They really, really want to do so. I want to provide this
> >Legacy apps like gcc, make, vim, emacs, bash, find, mc, mysql, apache,
> >samba, and netatalk? I think it's worth a bit of effort to make those
> Why would we care about those? Those aren't the target applications and
> their needs are 100% irrelevant to our design.
Also not true. How many gnome users are there who have never used any of
those programs? Maybe you would like it to be zero, but it's not even
Actually *supporting* those apps is a lot of work, and I'm not saying you
should do it. Just make sure it's possible to do.
> I doubt it will do everything POSIX can, at least not anywhere near as
> efficiently or easily in certain cases. It's not intended to. It's
> made to read and save documents, browse folders, and do basic file
> management. If you want more, don't use Desktop VFS - use NFS or FUSE
> or something else. D-VFS is in no way meant to deprecate FUSE or other
> system-oriented network VFS systems. D-VFS's just meant to provide an
> alternative that makes far more sense for a certain target set of
> applications (desktop apps and graphical file managers).
POSIX itself is incredibly weak, so making your API *able* to support it is
no big deal. Being efficient does not need to be a goal of your project,
because someone else can just speed it up later if needed. But making
things *easy* should certainly be a goal of yours, and given that POSIX does
a bunch of stuff that everyone wants to do, most of those things should be
Your API can trivially be POSIX-capable without much extra work. I think
you should think of that as a design goal as early as possible, or you end
up with more GnomeVFS or kioslave limitations.
More information about the xdg