Ideas for how the sockets stuff could work:

We need several parts for it to work:
	A language for client/server to interact with.
	A protocol guiding interactions.

=================== The protocol ==================================

The protocol is context-free.  So, no commands require responses; and
responses are simply commands.

The client may send updated info at any time, and the server decides
whether to display it.  An ideal communication may flow like this:
	client->server		server->client
	------------------	-------------------
	 (idle)			 (nothing)
	 (idle)			"I'm listening"
	new stats...		 (nothing; displays updated stats)
	new stats...		 (nothing...)
	new stats...		 (nothing...)
	new stats...		"Okay, be quiet"
	 (idle)			 (nothing; displays new screen)
	...			...
	 (idle)			"Your slider moved up"
	Set slider value: 43	(nothing; displays updated slider)
	 (idle)			(nothing)
	...			...
But the client could safely continue to send new stats, knowing that
the server isn't listening and won't display it.  Also, the client could
ignore the slider change, and the slider onscreen simply wouldn't move.


=================== The syntax ==================================

Gareth suggested that we make the language ascii-based, so a human can
telnet to a port and talk to the server.  This helps with development
and debugging.

With that in mind, the following syntax seems good:

	function arg1 arg2 arg3 ...

The syntax dictates that the first word is a function name, and the
rest of the line is passed to that function as an argument.
String-type arguments should always come last.  So, for example:

	set_label 23 3 2 Hey, booger.  What's up?

The first argument is a label id number, the 2nd and 3rd are x,y
coordinates onscreen, and the rest of the line is a string.


=================== The command set ==================================

The naming convention dictates that function names are lower-case,
with underscores ("_"'s) between words.

The naming convention also requires that function-name words go in
descending order.  So, "screen_set_priority" would be okay, but
"set_screen_priority" would not.

We're not sure yet if #id's are numbers or strings.

In general, we're trying to keep the command set small.  Especially the
server->client functions, so that clients won't have to handle a lot of
different types of input.

Now, the function list:

client->server functions
-------------------------
hello
	Client init
client_set_name name
	Set client's name
client_add_key #id
	Tells the server the client can handle keypresses of type #id.
	#id is probably just "A", "B", and so on...
client_del_key #id
	Tells the server to never send that keypress.
	All keypresses are disabled by default.

screen_add #id
	Add a new screen
screen_del #id
	Remove a screen
screen_set #id #priority name
	Initialize a screen, or reset its data.
screen_add_widget #screen #id type
	Add something onscreen
	Widget types can be any of the following:  "string", "hbar",
	"vbar", "title", "icon", ... "scroller"? ... more later?
screen_del_widget #screen #id
	Kill something onscreen
screen_set_widget #screen #id data
	Set (reset) widget's data
	Note that the "string" type should be used for frame buffers.
	The widgets take these arguments for data:
		string		x y text
		hbar		x y length
		vbar		x y length
		icon		x y binary_data
		title		text
		scroller?	x y direction text
			A scroller is a string which scrolls.

menu_add #id
	Add a new menu.  
menu_del #id
	Get rid of a menu.
menu_set top name
	if (top == True) Gets added to "Client Menus".
	else Client must insert it into its own menu heirarchy.
menu_add_item #menu #id
	Add a new, blank menu item.
menu_del_item #menu #id
	Delete a menu item.
menu_set_item #menu #id type [value] text
	(re)Set the menu item's data.
	If type is "checkbox" or "slider" or "menu", [value] should
	contain appropriate info.  (like 43, True, or #menuid)


server->client functions
-------------------------
connect args
	Verifies connection; gives info about the LCD, etc...
bye
	Notifies the client of a server shutdown.
huh? [info]
	Notifies the client of a request error.
listen level #screen [#widget [#widgets...]]
	Notifies client that "server is listening for data".

	The "level" is the severity.  "green" tells the client that
	the server is simply listening.  "yellow" is a more serious
	request for data, and "red" means "give me data or die".  A
	client which ignores a "red" request will have its connection
	closed, and all data freed.
	
ignore level [#screen [#widget [#widgets...]]]
	Tells the client "shut up".
	The "level" is the same as in "listen".

key #id
	Sends a keypress to the client.

menu #menu #item #action
	Tells the client that a menu item was selected/used/etc...
	The action can be "click", "up", or "down".  The client should
	handle this according to what type of menu item has been
	activated, and should probably send the server a new item
	definition if the item was a checkbox or slider.
