- Try to turn wmsound into a totally dynamic program, and independent of
  any predefined sound events.  I think we could do this in the same 
  fassion as wmsound, and wmaker communicate. We would need a new Atom
  probally something like WM_WMSOUND_FUNCTION.  Here's how I envision this
  working.
	
	All sound events used by WindowMaker are defined in WindowMaker's
	wmsound.c.

	WindowMaker starts up, and grabs WMSound, then says 'Hey, I have
	these sound events defined, can you give me an event number for them?'

	WMSound will reply 'sure, I have a free event here, so assign ?? 
	event to XXX', then WindowMaker would restore that id into a table
	of some sorts, so it can find it later.

  I've worked with a system kind of like this one while administrating a
  MUD, where certin numbers were defined at runtime, instead of defined
  at compile time.  If WMSound works this way, then any number of programs
  could use WMSound to play events, without patching wmsound.  That would
  be a great benefit.

- Write a small WMSound library so others can use wmsound in their programs?
  I don't think this would be hard at all, since all the must have functions
  for getting a dynamic sound server going could be written once, instead of
  re-written by every programmer that wants sound support in their program.

- Support way more sound formats.  Midi, Mpeg, AU, and what ever else I can
  think of.  Oh yeah and add e-mail as the last feature. j/k.

