Fwd: Re: A common VFS and a Common conf-system [Part II]

[gtg990h at mail.gatech.edu]

Quoting Sean Middleditch <elanthis at awesomeplay.com>:

> The entire web, for one.  KDE is a big one.  All of the remote shares
> that GNOME does use are URI accesses.  Pretty much any and all
> applications that include their own VFS-like system use URIs, such as
> Vim.

>From the user's perspective, the web doesn't contain files, it contains "web
pages". CIFS shares, however, contain files. The user will want to use file
naming conventions when accessing their "network drive", and D-VFS should allow
them to. As for KDE and GNOME: the percentage of users that consider URIs to
refer to files is probably a fraction of a percent of users. If it weren't, KIO
and GNOME wouldn't have special-cases translating POSIX paths to file:/// URIs,
would they?

> No, file naming and namespace at a very low level are OS concepts.  At a
> higher level, there is the OS agnostic URI.

To the extent that URIs and file paths overlap, they are the same concept. When
they overlap, file paths should be preferred. Otherwise, it'll just be
confusing. If I've got a text file on my samba drive, I don't want to have to
use "smb://foo/bar.txt" in gedit, and "/mnt/smb/foo/bar.txt" in my CLI.

> acceleration that X makes rather difficult.  But yet X exists, and shall
> continue to exist, because the benefits it brings are far greater than
> those of the framebuffer.

It's ironic that you reference X, simply because it's one of the classic
references to the power of the UNIX API. X was implemented entirely on top of
the basic UNIX device files. It has since gone the way of "doing its own thing",
but work is underway to remedy that :)

> The existing sycalls do not work.

I'm sure that's news to those people who've been using them for 30 years. The
vast majority of computers today use a filesystem API that maps closely to
POSIX. The paradigm might be inconvenient, but it's just wrong to say that they
"do not work".

> It doesn't solve the fact that you must manually mount
> remote shares.

That argues for fixing the mounting mechanism, not ditching the entire kernel
file access layer.

> It doesn't solve the fact that you can only do that on
> Linux.

And OS X and Windows.

> Your solution forces each and every single application to be forever
> trapped with the vastly limited and difficult to use POSIX APIs.  The
> D-VFS solution lets your old POSIX apps continue to work pretty much
> spot on while allowing new applications to make use of more and better
> features.

No, it forces you into a situation where some apps use "new and better APIs" and
everything else uses existing APIs, and apps see the filesystem in different
ways. I think it's a really bad idea to assume that even half of apps will ever
use D-VFS. To the extent that everyone not using D-VFS causes an inconsistent
user experience, there is a problem.

> Lots and lots and lots code.  The file:// backend will also be one of
> the least reliable.

That's wonderful to know, given that it'll be the single most used protocol
handler. If D-VFS semantics cannot be implemented properly for file://, I would
question the necessity of those semantics. I can see why POSIX would be
insufficient for something like the IMAP case mentioned today, but it really
*needs* to be sufficient to properly implement file://. To the extent that
file:// is implementable using POSIX, so should sshfs, samba, and a bunch of
other interesting filesystems.

> In the case of the file:// backend, POSIX usually is the end target.  In
> the case of remote shares, POSIX would sit between the backend and the
> application, getting in the way.

It depends on the protocol. If it really does get in the way for a give
protocol, the D-VFS daemon doesn't need to force the issue. However, it's
unlikely that the user will want to use existing tools on such a protocol
anyway.

> So in other words, you want duplication of effort.

Yes. Those native services will exist, regardless of what happens to D-VFS. That
effort will be exerted, and indeed already has been exerted. If taking advantage
of that effort allows more integration, then at least something can come of it.

> The OS itself does not support SSH.  if it does, the OS is scary and you
> should stop using it, because it's probably also full of security holes
> and other bad code...

I'm sure MacOS users will love to hear that.

> My solution is 100% in line with what you want, provides everything you
> want, and provides it in a cleaner way.

Let's try to make this concrete. Would what you propose that would make D-VFS be
"100% in line with what [I] want" resemble FUSE-KIO? Because everything in the
current concept points in that direction. FUSE-KIO is exactly what I don't want,
because it's a hack, and it's not transparent to CLI apps.

> Imagine that you want to access an FTP share.  You need to enter a
> password.  Are you suggesting that I type in,
>
> cat /remote/ftp/user at pass:server/pub/file.txt  ?

That's a trick question. The paths wouldn't have to auto-vivify. The cat would
fail because /remote/ftp/server/pub wouldn't exist, and the user would have to
mount the directory manually, using the existing mechanisms (like sshmount).
That's consistent with the way things are now, and shouldn't confuse users.
Meanwhile, if the same path is accessed via the D-VFS API, the D-VFS daemon
could handle the mount itself, and provide the password because presumably it
knows it.

> No, I'm going to put them in the implementation.

Ok, the wording confused me. Saying that word "required" signals to me "it will
be in the spec", for the simple reason that fd.o is a site for promulgating
specs. For the record, I agree that the daemon is essential, except maybe for
something like Plan9.
----- End forwarded message -----


--