experimental, extensible Linux NFS server soon to be available

[Tom Lord]

Newsgroups: comp.os.linux.announce
Subject: experimental, extensible Linux NFS server soon to be available
Summary:
Expires:
Sender:
Followup-To:
Distribution: world
Organization: LanMinds, Berkeley. Not responsible for content.
Keywords:
Cc:

This announcement is about the availability of a new source code
package called snfs, which stands for Systas-NFS. Systas, in turn,
stands for "systems application scheme", a temporary branch from the
main line of development of GNU Guile. Work to remerge this branch to
the main line is just now beginning.

SNFS is based on a simple, but powerful idea. Here it is:

A unix NFS file server is a program that performs unix system calls
and directory-reading functions to examine a real file system. The
same program listens on network connections for requests from NFS
clients. Each request is answered by examining the file system and
formatting a suitable reply.

In SNFS, the server's interface to the file system has been
abstracted. System calls and directory reading functions have been
replaced by call-outs to user-supplied Scheme procedures. This opens
the door to a great many possibilities. The server might "experience"
via system calls a real file system, or it might find itself in a
virtual file system whose precise semantics are determined by Scheme
programs. In either case, the clients just sees an NFS file system,
though one in which the basic file operations may be overloaded to
have extra semantics beyond those required of any NFS implementation.

A few of the potentials of this server are user-space implementations
of file systems with non-standard semantics. Examples include:

union filesystems

copy-on-write file systems

caching file systems

first-served file systems -- a proxy for redundant servers for
the purposes of performance or reliability

file systems mapping portions of web space into nfs space

file systems mapping portions of ftp space into nfs space

control files -- write to them and something unusual happens,
beyond what you might expect

process files -- files and directories whose contents are interfaces
to a running program

cgi files -- files and directories whose contents are the
output of running a program and whose names
are a parameter to that program

email trees -- file systems that contain incoming as well
as already-filed email

The basic architecture of this system, a simple event loop processing
rpc requests and accessing the file system, is well suited to being
opened up to include the possibility of out-of-band communications
with the server, perhaps by means of special files embedded in the
namespace served, or perhaps by bypassing the NFS protocol entirely.

This server is free software, currently operational on Linux. It
comes with some Scheme code implementing parts of the ftp client
protocol and the pop3 mail client protocol.

Incidentally, the number of changes to the Linux NFS server were quite
small and simple. Any extension language implementation could easily
be adapted for this purpose or the same approach could be taken using
functions written in C. That is the primary reason for posting this
message to some of the groups to which it has been posted.

[Jon Leech]

In article <51q10o$3...@emf.emf.net>, Tom Lord <lo...@emf.emf.net> wrote:
>Incidentally, the number of changes to the Linux NFS server were quite
>small and simple. Any extension language implementation could easily
>be adapted for this purpose or the same approach could be taken using
>functions written in C. That is the primary reason for posting this
>message to some of the groups to which it has been posted.

You appear to be saying that if someone writes an application in
language A that could equally well be written in language B, an announcement
of that application should therefore be made to comp.lang.B.
Jon
__@/

[Jim Ingham]

It seems that Tom was saying, "I have a really cool idea for taking
advantage of extensible scripting languages. The proponents of each one of
these scripting languages may want to consider whether this is a good
opportunity to leverage the power of their tools. I have implemented the
idea in one scripting language, so there is even example code that you can
work from."

You may or may not think the idea is cool (seems pretty neat to me, in
fact), but he was doing a service, and certainly does not deserve a
snippish message for his efforts.

Different extension languages do not have to constitute opposing camps.
Rather it is in all our interests to share ideas about new domains where
this type of language shows its power. As to the particular
implementation, "Let 100 flowers bloom and 100 schools of thought contend"*

Jim.

*Those who recognise the historical analogy will understand that if we do
not foster a diverse community, then Chairman Bill will come and force
Visual Basic down our throats... :-(