! Outstanding Issues & ideas

1) Socket protocol
	Use iterated forms for read & write:
	Socket.read[buffer, rsize, count, index]
	Rsize must one of 1, 2, or 4 bytes. It is required
	to control the network byte order conversion.
	Count specifies the number of byte (not records)
	to be read.
	If the required number bytes are not available, the
	caller is blocked.
	
	When index is specified, a non-blocking read is done
	and the and the available data is copied to the buffer
	starting at the position specified by index. The value
	returned by the message is a new value for index.
	(Index is set to zero when a new buffer is to filled.)
	The idea is to send the read message with the updated
	value for index in a periodic method. When count=index,
	the buffer is full.
		
	For write we have:
	Socket.write[buffer, rsize, count, index]
	If index is specified, a non-blocking call is used and
	the value returned is an update to index. The idea is
	to call write again and again with the updated index
	value until count=index.
	
	s.accept will leave s.error true until a connection
	has been accepted.
	
	s.listen[port] will establish s as a listener for the
	specified port.
	
	s.connect[dest, ip] is always non-blocking. It is impossible
	to know if the connection was accepted, but attempts to read
	data will fail and writes will eventually fill the buffer and
	not accept further values.

2) Arbitrary font support:
	(Done 2/17/98)
	Fonts in saved images can't be system id's so
	a change is required to keep the parameters around
	to recreate a system font.
	This required introducing a new kernel class: Font.

3) Mode for highlighting text
	This has to work as written, so make then	
	change based on the screen depth.
	Update: A better way is to make the change based
	on the TrueColor attribute.
	(Done 2/20/98)
	
4) Mode for deactivating controls
	This needs some experimentation.
	Using XOR is probably not the answer.
	Simply 'fading' all the colors might
	work. Blacks would go to grey by this
	means.
	Update: A better way is to not do this with
	modes at all. The only View classes that used
	this mechanism were the Buttons. A simple
	change to the drawOutline method takes care
	of inactive Buttons and they look better too.
	
5) Support stand-alone applications
	(Done 2/26/98)
	This is easy with Unix: simply append the heap
	onto the end of the executable. This might work
	well for Windows as well allowing both to use
	a portable module.
	
6) Dealing with polygons:
	Three methods:
	a) (Easy) Keep a big polygon buffer array in gw.
	When the user passes an Alltalk polygon spec, copy
	the array elements to the Points in the polygon and
	render it in the usual manner.

	b) (Hard) Manage polygons like images. In this case,
	we have a new Alltalk kernel class Polygon that contains
	the public data structure and a private rep inside of
	the gw module. This has the advantage of being faster
	because large polygons don't have to be copied. It has
	the drawback of being complicated and  that large
	polygons are unusual in most GUI apps.

	This suggests that type 1 would be best...

	c) Paul used an malloc and free to build the Polygon
	array. This could fragment the heap if a wide range
	of sizes occur. It also take a non-determinant time
	to allocate and deallocate. It has the advantage of
	working with no size limits.


	We can do a pretty good GUI without using Polygons
	at all. The arrows and diamonds can be bitmaps...

