[Portland] PortlandVFSProposal

[Diego Calleja]

> With fs semantics you are loosing the efficiency and functionality of the 
> protocol. 
> 
> E.g. IMAP4 knows about unsolicited server responses. How do you intend to 
> implement this with fs semantics?

Of course, not *everything* can be simplified to a file/directory scheme.

That isn't true only for FUSE, it's true for _anything_ that tries
to abstract things as filesystems. You can design common-vfs API to handle
that particular IMAP issue, but then you'll find other protocols
that just don't make sense in common-vfs, and that's because some
protocols just suck and others are just too weird ans specialized and you
can't do anything about that. Abstracting has advantages and disadvantages.

In order to get the best things of IMAP or any other weird protocol you
just can't use FUSE or common-vfs: You just do things like they're done
today, you use the IMAP protocol natively in your app. Hey, if people here
decides that getting the full semantics of every protocol candidate to
be implemented as userspace filesystems is a must for modern desktops
we can stop talking right now, we're doing OK today.


The plan 9 paper (http://plan9.bell-labs.com/sys/doc/9.html which is, as
far as I know, probably the best example of userspace filesystems done
the Right Way) already contains some words about this:

"Nonetheless, it is possible to push the idea of file-based computing
too far. Converting every resource in the system into a file system is a
kind of metaphor, and metaphors can be abused. A good example of restraint
is /proc, which is only a view of a process, not a representation. To run
processes, the usual fork and exec calls are still necessary, rather than
doing something like 

    cp /bin/date /proc/clone/mem

The problem with such examples is that they require the server to do things
not under its control. The ability to assign meaning to a command like this
does not imply the meaning will fall naturally out of the structure of
answering the 9P requests it generates. As a related example, Plan 9 does
not put machine's network names in the file name space. The network
interfaces provide a very different model of naming, because using open,
create, read, and write on such files would not offer a suitable place
to encode all the details of call setup for an arbitrary network. This
does not mean that the network interface cannot be file-like, just that
it must have a more tightly defined structure."