You might get a kick out of Sun's proposal for "NFS 3.0" aka "NeFS". The basic idea was to put a PostScript interpreter in the kernel for extensibly and efficiently executing distributed and even local file system operations. It not only cuts down on network transactions for the same reason NeWS and AJAX does, but even locally you can avoid billions of context switches by executing "find" and tasks like that in the kernel, for example.

The Network Extensible File System Protocol Specification 2/12/90

http://www.donhopkins.com/home/nfs3_0.pdf (pages in reverse order)

Introduction

The Network Extensible File System protocol (NeFS) provides transparent remote access to shared
file systems over networks. The NeFS protocol is designed to be machine, operating system,
network architecture, and transport protocol independent. This document is the draft specification
for the protocol. It will remain in draft form during a period of public review. Italicized comments
in the document are intended to present the rationale behind elements of the design and to raise
questions where there are doubts. Comments and suggestions on this draft specification are most
welcome.

1.1 The Network File System

The Network File System (NFS™) has become a de facto standard distributed file system. Since
it was first made generally available in 1985 it has been licensed by more than 120 companies. If
the NFS protocol has been so successful why does there need to be NeFS ? Because the NFS protocol
has deficiencies and limitations that become more apparent and troublesome as it grows older.

1. Size limitations. The NFS version 2 protocol limits filehandles to 32 bytes, file sizes to the
magnitude of a signed 32 bit integer, timestamp accuracy to 1 second. These and other limits
need to be extended to cope with current and future demands.

2. Non-idempotent procedures. A significant number of the NFS procedures are not idempotent.
In certain circumstances these procedures can fail unexpectedly if retried by the client. It is not
always clear how the client should recover from such a failure.

3. Unix bias. The NFS protocol was designed and first implemented in a Unix environment.
This bias is reflected in the protocol: there is no support for record-oriented files, file versions
or non-Unix file attributes. This bias must be removed if NFS is to be truly machine and
operating system independent.

4. No access procedure. Numerous security problems and program anomalies are attributable to
the fact that clients have no facility to ask a server whether they have permission to carry out
certain operations.

5. No facility to support atomic filesystem operations. For instance the POSIX O_EXCL flag
makes a requirement for exclusive file creation. This cannot be guaranteed to work via the NFS
protocol without the support of an auxiliary locking service. Similarly there is no way for a
client to guarantee that data written to a file is appended to the current end of the file.

6. Performance. The NFS version 2 protocol provides a fixed set of operations between client and
server. While a degree of client caching can significantly reduce the amount of client-server
interaction, a level of interaction is required just to maintain cache consistency and there yet
remain many examples of high client-server interaction that cannot be reduced by caching. The
problem becomes more acute when a client’s set of filesystem operations does not map cleanly
into the set of NFS procedures.

1.2 The Network Extensible File System

NeFS addresses the problems just described. Although a draft specification for a revised version of
the NFS protocol has addressed many of the deficiencies of NFS version 2, it has not made non-Unix
implementations easier, not does it provide opportunities for performance improvements. Indeed,
the extra complexity introduced by modifications to the NFS protocol makes all implementations
more difficult. A revised NFS protocol does not appear to be an attractive alternative to the existing
protocol.

Although it has features in common with NFS, NeFS is a radical departure from NFS. The NFS
protocol is built according to a Remote Procedure Call model (RPC) where filesystem operations
are mapped across the network as remote procedure calls. The NeFS protocol abandons this model
in favor of an interpretive model in which the filesystem operations become operators in an
interpreted language. Clients send their requests to the server as programs to be interpreted.
Execution of the request by the server’s interpreter results in the filesystem operations being invoked
and results returned to the client. Using the interpretive model, filesystem operations can be defined
more simply. Clients can build arbitrarily complex requests from these simple operations.