sdf fields:

	Fields in the .sdf file should be labeled with a full length
	string instead of a single character. So instead of
		f /sndc/rusty/beep
		o rusty
		R 16384.000000
		P s
	you'd have
		file_name	/sndc/rusty/beep
		owner		rusty
		sample_rate	16384
		packing_mode	s

	All of these fields will be passed about by the procom routines.
	Each program is free to ignore or interpret them as it pleases,
	and they may add more fields which the sndio routines will add
	to the .sdf file.

symbolic links:

	Use symbolic links to make a sort of virtual sound file
	in the current unix directory.

	When the user says
		sndout foo
	it would create the .sdf file on the sound file disk in the
	usual manner, but it would also make a file in the current
	unix directory that is a symbolic link to the .sdf file.

	Saying
		sndin foo
	would open the symbolic link in the current directory which
	would cause it to be actually opening the .sdf file on the
	sound file disk. If the .sdf file doesn't exist then unix
	will cause the open to fail.

	When the user does
		mv foo bar
	this creates an inconsistency, but it is easily handled.
	When the next sound file program references "bar" it will
	check that the .sdf file that "bar" is a link to has the
	same soundfile name, if not then it will fix the .sdf file.

	The only problem is when one does
		rm bar
	One idea is to have a daemon process that periodically examines
	all .sdf files and verifies that they have a symbolic link to
	them. If not then the zombie soundfile is rmsf'd.  This is
	presumably no worse than the system which does buffer flushing
	at periodic intervals with sync().  An additional program,
	sfsync, could exist that would send a signal to the sound file
	daemon to do an unscheduled flush, freeing the space immediately.

	Another idea would be to just leave the .sdf files around until
	a program that reads .sdf files directly (sfck, purgesf, etc.)
	is run and it will remove them. With this scheme it is probable
	that the disk would run out of inodes or disk space at some
	point.  In that case the sound file open routine would call the
	routine that deletes zombie soundfiles.

sound file system quotas:

	It would be nice if the sound file system had a quota system
	like 4.2bsd does.

	It would have to be more flexible than 4.2bsd, however, since 
	sound file usage by any one user can vary wildly for legitimate
	reasons.  Best thing to do would be to measure the usage per unit 
	time.
