[Fwd: [PROP] Socket Portability Classes (was Re: Taking Swazoo Forward [Long])]

Just in case this didn't get through to the list, here it is again.


Ken

Jerry Bell wrote:

I agree that keeping the code in sync across platforms may be a problem.
The Dolphin port is quite behind, but my free time situation should be
improving soon.  I'm planning to let the current changes to the VW parcels
settle, and then port those changes to Dolphin.

Still, there will still be some lag in propagating changes across platforms
unless we are able to figure out some way to isolate code that is completely
portable across platforms from code which isn't.  The lag probably won't be
too drastic, so it may not be worth the effort.  Also, it probably makes
sense to wait until a Squeak port has been completed, so that we have 3 data
points as to what bits aren't completely portable.

After reading this (and a couple of your other messages) as well as doing some Squeak playing on my own, I'd like to propose the following changes to the Swazoo socket code.  Hopefully, these should ease portability -- at least as far as the socket layer goes.

Change 1: Pull the socket-serving code out of HTTPServer.  In this scenario, the HTTPServer would instantiate a SwazooSocketServer.  The socket server's job is to create a listening socket, block waiting on it, and evaluate a block -- a handling block, if you will -- with a newly accepted stream as an argument.  Then, the HTTPServer code looks something like this:

initialize
    ...
    server := SwazooSocketServer port: port.
    server handler: [:stream | self interactWithNewConnectionOn: stream]

start
    server startServing

interactWithNewConnectionOn: aStream
    conn := HTTPConnection stream: aStream.
    self addConnection: conn
    conn interact

There are parts of this operation that'll be platform specific -- we have to create a new socket, listen on it (this object will encapsulate the serveLoop that's now in HTTPServer), create a new stream, evaluate the handler, and repeat.  Therefore, I propose that we make an AbstractSwazooSocketServer (the name doesn't have to be that heinous) that has as much common code as is possible.  Then, we implement a SwazooSocketServer subclass in each dialect.  HTTPServer should then be completely portable.

I'm not sure how we'd test this -- ideas?  Perhaps we could create internal streams, call the interactWithNewConnectionOn: method ourselves, and make sure that the server appropriately creates new connection objects, adds them to its collection of them, and starts them up.

Change 2: We do the same kind of thing with our streams.  VisualWorks lets you create a readAppendStream on any socket.. while Dolphin has some sort of socket stream and Squeak's sockets don't behave like streams at all (though it's not hard to make them do that -- I've written one that we could use as a starting point).  SwazooStreams would need to do the standard stream operations (most of which could be written in an abstract class), and we'd also make them able to tell you what the IP address of the remote site is.  Perhaps we could even put utility methods in SwazooStream class for name resolution if we need them.

SwazooStream would wrap whatever dialect-specific stream is needed, and most of the methods in SwazooStream would just forward to it.  That gives us a unified interface to the streams across dialects.  We could also make our own protocol for binary puts (e.g. nextPutBytes:, since most of the time we want to spew raw bytes in large chunks) instead of using the VisualWorks binary/text mode flipping.  Heck, we could even add SwazooStream>>crlf, nextLine, etc, thus eliminating the need for the silly LineStream.

This should be pretty easily testable, too, if we just point the SwazooStream at an internal stream and test the behavior of nextPut:, next:, and the like.

----

All of this is to try to isolate the non-portable parts so that it's easier to keep our different Swazoo ports up to date.  Every Swazoo resource should use the SwazooStream protocol, and then Swazoo apps will at least be portable in that respect.  Other hurdles might include an EndOfStreamNotification (we can probably make SwazooStream handle this), as well as any references to ObjectMemory (doesn't work for Dolphin).

Thoughts, everyone?
 

Ken Treis
[hidden email]